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But peace to vain regrets! We see but darkly 
Even when we look behind us, and best things 
Are not so pure by nature that they needs 
Must keep to all, as fondly all believe, 

Their highest promise. If the mariner, 

When at reluctant distance he hath passed 
Some tempting island, could but know the ills 
That must have fallen upon him had he brought 
His bark to land upon the wished-for shore, 

Good cause would oft be his to thank the surf 
Whose white belt scared him thence, or wind that blew 
Inexorably adverse: for myself 
I grieve not; happy is the gowned youth, 

Who only misses what I missed, who falls 
No lower than I fell. 


The Prelude, or Growth of a Poet’s Mind 
William Wordsworth, 1850 
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Abstract 


This thesis studies questions of type inference, unification and elaboration for lan¬ 
guages that combine dependent type theory and functional programming. Lan¬ 
guages such as modern Haskell have very expressive type systems, allowing the 
programmer a great deal of freedom. These require advanced type inference and 
unification algorithms to reconstruct details that were left implicit, and suitable 
representation of the evidence delivered by such algorithms. 

The first part proposes an approach to unification and type inference, based on 
information increase in dependency-ordered contexts, and keeping careful track 
of variable scope. Two existing systems are reviewed: the Hindley-Milner type 
system, and units of measure in the style of Kennedy. Subtle issues relating to 
let-generalisation become clearer as a result. Using the same approach, an algo¬ 
rithm is described for Miller pattern unification in a full-spectrum dependent type 
theory, forming a foundation for the elaboration of dependently typed languages. 

The second part introduces inch , a language that extends Haskell with type- 
level data and functions, and dependent product types. Type-level numbers and 
arithmetic operations are specifically considered, as a particularly useful source 
of applications, such as the perennial example of vectors (length-indexed lists). 
The increased expressivity in the source language is matched by a suitable core 
language of evidence , into which inch programs can be translated. This language 
is based on System F c , the existing core language used by GHC, adapted to 
clarify the relationships between the type and term levels. It gives a coherent op¬ 
erational semantics to both levels, allowing shared data and dependent functions, 
but retaining a clear phase distinction. The contextual approach of the first part 
of the thesis is used to specify the elaboration of inch into the evidence language, 
and applications of inch based on type-level arithmetic are demonstrated. 




Part I 

Foundations of type inference 



Chapter 1 
Introduction 


This thesis explores the combination of the functional programming language 
Haskell with dependent type theory. It is addressed to the functional program¬ 
mer who wants a language that provides stronger static guarantees and a more 
expressive type system than modern Haskell, while maintaining the phase dis¬ 
tinction and useful, if not necessarily complete, type inference. I will assume the 
reader has some familiarity with Haskell or a similar functional language, but not 
necessarily a great deal of familiarity with type theory. Experience of advanced 
type system features such as generalised algebraic datatypes and higher-rank 
types would be beneficial. 

Haskell is a functional language with Hindley-Milner type inference in the 
tradition of ML. Thanks to type inference, the burden of type annotations is 
minimised, if not necessarily eliminated. 1 Moreover, the typeclass system enables 
term inference: types function as a real aid to the programmer, not just a safety 
net that prevents bad programs, as the compiler can write runtime code for the 
user. For example, Haskell’s Eq typeclass can be used to compute an equality 
test for complex structured data from the equality tests on the component types. 

Dependent types allow term-level data into the static type system. This allows 
more precise invariants to be specified: for example, rather than the type of lists 
of arbitrary length, one can work with the type of vectors of a statically-known 
length. Term inference becomes easier, because the presence of terms in types 
leads to equational constraints on terms, and solving these constraints may allow 
the compiler to discover runtime-relevant values. While typeclasses allow terms 
to be discovered by evaluating logic programs, dependent types allow them to be 
discovered by solving equations in the underlying functional language. 

1 1 include approaches requiring a little annotation, sometimes called ‘type reconstruction’, 
under the general term ‘type inference’. Type inference is pure if no annotations are required. 







Haskell is a good basis for extension with dependent types because it is already 
widely used as a testbed for type system extensions. Numerous advanced features, 
that push the boundaries of type inference, have been adopted in the Glasgow 
Haskell Compiler (GHC): notably higher-rank types, which allow universal quan¬ 
tification in the domain of a function, and generalised algebraic datatypes, which 
allow data constructors to introduce equational constraints on types. While such 
extensions make pure type inference infeasible, this can be a price worth paying, 
particularly given the huge increase in expressivity achieved, the potential for 
term inference and the value of annotations as machine-checked documentation. 

1.0.1 Contexts, variable scope and let-generalisation 

One of the main themes of this thesis is the proper management of variable 
scope, which is crucial for correctly implementing type inference. Type inference 
algorithms create existential variables to stand for unknown type expressions, 
then solve for these variables by unification. Once higher-rank types are available, 
it is necessary to carefully manage which universally quantified variables are in 
scope for each existential variable. Even in the Hindley-Milner system, however, 
variable dependencies are key to understanding the process of let-generalisation. 

Let-generalisation is used to assign polymorphic types to definitions. In 

let f x — ( x , x) in (/ True,/ 3) :: ((Bool, Bool), (Int, Int)) 

the term is well-typed because / is assigned the type V a . a —> (a, a). This type 
is determined by inferring the type j3 —>■ (/5, /3), where /? is an existential variable, 
then quantifying over f3. In more complex examples it is not always possible to 
quantify over all the existential variables, as they may have meaning outside the 
local scope of the let-binding. This will be examined in more detail in Chapter 2. 

All this motivates taking more care over metavariables than is traditional 
for the Hindley-Milner system. I will introduce a notion of context that tracks 
metavariable declarations and imposes a dependency-respecting order upon them. 
Considering contextualised unification and type inference problems leads to a 
precise notion of the minimal commitment necessary to solve a problem, and 
reveals the underlying structure that makes sense of the let-generalisation step. 
This structure makes it easier to deal with systems where variable dependency 
is more subtle than in Hindley-Milner, such as units of measure in the style of 
Kennedy (2010), considered in Chapter 3. Contexts can be extended to contain 
universal as well as existential variables, a ‘mixed prefix’ in the language of Miller 
(1992), allowing the analysis to be extended to dependent types, as in Chapter 4. 
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1.0.2 Dependent types in GHC Haskell 

Simulating dependent types in Haskell is a cottage industry (McBride, 2002), 
and recent extensions to GHC allow some dependent datatypes to be defined 
reasonably neatly. The standard example of vectors of a fixed length is given by: 

data N = Zero | Sue N 
data Vec :: * —^ M ^ * where 
Nil :: Vec a Zero 

Cons :: a — * Vec an—)- Vec a (Sue n) 

Datatype promotion (Yorgey et al., 2012) allows the data type N to be used in the 
kind of Vec, and correspondingly the Zero and Sue data constructors appear in 
the types of Nil and Cons. Moreover, Vec am is a generalised algebraic datatype 
or GADT (Peyton Jones et al., 2006), meaning that pattern matching on its 
constructors supplies information to the typechecker: a proof of the equation 
m ~ Zero in the Nil branch, and a proof of m ~ Sue n in the Cons branch. 

This type-level knowledge of length is useful for expressing more precise in¬ 
variants in types, leading to more reliable code. The tail function for vectors 

tail :: Vec a (Sue n) —» Vec a n 
tail (Cons _ xs) = xs 

statically enforces the invariant that its argument list must be non-empty, so this 
definition is total, and it is guaranteed to return a result of the right length. 

Type families (Chakravarty et al., 2005), which approximate functions on the 
type level, allow the definition of operations on type-level data. Addition for 
type-level naturals can be defined, then used in the type of vector concatenation: 

type family (m :: N) + (n :: N) :: N 

type instance Zero + n = n 

type instance Sue m + n = Sue (m + n) 

append :: Vec a m —>• Vec a n —>• Vec a (m + n) 

append Nil ys = ys 

append (Cons x xs) ys = Cons x (append xs ys) 

However, type families do not correspond exactly to term-level functions, because 
they are open, that is, defining equations can be added anywhere. They are not 
translated into case analysis, but are understood as rewrite rules on the syntax 
of type expressions. This gap between the term-level and type-level operational 
semantics is problematic for dependent types, where the same expression may be 
used both statically (in the typechecker) and dynamically (at runtime). 
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1.0.3 The value of II: going beyond GHC Haskell 

Vector concatenation relies only on (implicit) universal quantifiers and runtime 
functions. However, consider the vector version of the replicate function, which 
creates a vector of length n by repeating its second argument n times: 

replicate :: n (n :: N) —>• a —>• Vec a n 

replicate Zero = Nil 

replicate (Sue n) x = Cons x (replicate n x ) 

Here the result type Vec a n depends on n, but the operational behaviour of the 
function also makes uses of n, as it is defined by pattern matching. This shows 
the need for the dependent product n: it is a function space where the value 
is available both statically and dynamically. GHC Haskell does not currently 
support n, but it can be encoded in some cases. Adding n to Haskell is the main 
contribution of part II of this thesis. Chapter 5 describes the resulting language. 

1.0.4 Type inference and term inference 

Dependent type theory offers a significant extension of the verification that can 
be performed by types: ultimately, the full power of constructive mathematics 
can be used to specify and prove properties of programs. However, this power 
comes at a cost. Inferring the most general type of the composition operator 

(g°f)x = g{f x) 

is straightforward in Haskell, where it has type 
( b —y c) — y (a — y 6) — y (a — y c). 

If the codomain of / may depend on the value of x, and g may depend on x and 
f x , then the type becomes more complicated. A possible type for composition is 

{ A : Set} { B : A —y Set} { C : (ft : A) —y B a —y Set} 

(g : { ft : A} (b : B a) —>• C a b) (/ : (ft : A) -y B a) (a : A) -y C a (/ ft) 

in Agda notation, 2 ignoring universe polymorphism. It is not reasonable to ask 
a machine to reconstruct this type from the definition. 

As I have noted, types are not simply a form of statically-checked documen¬ 
tation or a policing system that prohibits bad programs, important as these roles 

2 A dependent function space (II-type) is written (x : S) —> T or { x : .S’} —> T, where x is 
bound in T. The type Set is a universe of small types, resembling the Haskell kind *. 
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are. In exchange for writing more expressive types, the programmer can be re¬ 
paid by having to write less of their program: term inference becomes feasible. 
Typeclasses accomplish this to a certain extent, but the presence of computational 
data in types means that constraints on types can determine runtime information. 
The replicate function defined in Subsection 1.0.3 makes crucial runtime use of its 
natural number argument. If it is used in a context demanding a value of type 
Vec a 42, the programmer should not need to supply that argument explicitly! 

Users of a dependently typed language, if they wish to prove properties of 
their programs, have much work to do in choosing appropriate representations of 
data structures and ways to enforce invariants. On the other hand, significant 
benefits can be gained with less work by selectively establishing invariants that 
use the type system to prevent certain errors, guaranteeing the absence of a class 
of bugs, if not the absence of bugs altogether. Perhaps the way forward lies 
in a mixed economy: a system that combines the flexibility of Haskell with the 
reliability of dependent type theory. This is the approach that I will pursue. 

1.1 Outline 

This thesis falls into two parts: the first develops foundations for describing and 
analysing type inference, and the second builds on this work to introduce the inch 
system, extending Haskell with dependent types. Reference implementations of 
the algorithms in part I and details of selected proofs are given in the appendices. 

Part I: Foundations of type inference 

In Chapter 2, I start at the very beginning with a rationalised reconstruction 
of type inference for the Hindley-Milner type system, and its constraint-solving 
algorithm, first-order unification. This introduces a method of contextualised 
problem-solving that sustains the later development. Paying careful attention 
to variable scope makes evident the underlying structure on first-order unifica¬ 
tion that explains let-generalisation. Furthermore, I describe how to elaborate 
Hindley-Milner terms into System F, representing term structure in the context. 

Following on from this in Chapter 3,1 extend the basic Hindley-Milner system 
with Kennedy-style units of measure. This requires unification in the equational 
theory of abelian groups. I show how the contextual structure introduced in 
Chapter 2 makes let-generalisation straightforward, even in this more complex 
setting where variable occurrence does not imply dependency on that variable. 
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Taking a different direction in Chapter 4, I apply the same techniques of con¬ 
textualised problem-solving to higher-order unification, where the correct man¬ 
agement of scope is crucial. I describe an algorithm for Miller pattern unification 
in a full-spectrum dependent type theory. Higher-order unification is needed for 
implementing type inference for dependently-typed programming languages, as 
constraint-solving must take place in the definitional equality of the type theory. 
Not all equations can be solved immediately, so the algorithm must represent 
constraints explicitly and make most general progress where possible. 

Part II: Haskell with dependent types 

Having constructed the foundations, I build on them in the second part to create 
inch , a language based on Haskell with n-types and type-level data. In Chapter 5, 
I introduce the main features of the language by example and compare it to related 
work. This chapter contains a more thorough introduction to the encoding of 
dependently-typed programs in Haskell via GADTs and type families. 

To explain inch formally, I build an evidence language in Chapter 6, based 
on GHC’s intermediate language System F c , but influenced by Martin-Lof Type 
Theory. The evidence language is a very explicit calculus for which typechecking is 
straightforward. I give a precise account of the phase distinction, as n means that 
the categories of runtime and type-level data are no longer mutually exclusive. 
The operational semantics of the evidence language, with type safety proof, makes 
explicit the computational role of dependent n-types. Also, I present a new 
approach to proving consistency of coercions (which witness type equalities). 

In Chapter 7, I describe type inference for inch via elaboration into the evi¬ 
dence language, using the ideas of contextualised problem-solving from the first 
part of the thesis. In particular, the elaboration algorithm clarifies the man¬ 
agement of implicit and explicit arguments. Elaboration relies on an underlying 
constraint solver, which I do not study in detail, though it would use similar 
techniques to the unification algorithms from Part I. 

The payoff for all this work appears in Chapter 8, where I present applications 
of inch , using dependent types to provide stronger guarantees of correctness. I 
give examples of vector functions, merge sort and red-black tree insertion and 
deletion, and show how the time complexity of such programs can be statically 
checked. Additionally, I demonstrate an approach to units of measure as a library 
based on type-level integers, in contrast to the built-in treatment in Chapter 3. 

Finally, some concluding remarks form Chapter 9. 
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Chapter 2 

A rationalised reconstruction of 
Hindley-Milner type inference 


In this chapter I rebuild first-order unification and Hindley-Milner type infer¬ 
ence from the ground up. A key theme of this thesis is the proper understand¬ 
ing of scope, achieved by keeping variables (especially ‘unification variables’ or 
‘metavariables’) in contexts. Applying the variables-in-contexts approach to a 
standard type inference problem allows me to emphasise this theme, before mov¬ 
ing on to more advanced type systems. This chapter is based on the paper “Type 
inference in context” by Gundry, McBride, and McKinna (2010). Appendix A 
(page 197) contains a Haskell implementation of the algorithm described here. 

The Hindley-Milner type system 1 (Milner, 1978) consists of the simply-typed 
A-calculus plus ‘let-expressions’ for polymorphic definitions. For example, 

let x — Xy.y in xx 

is well-typed: x is given the polymorphic type Vcc. a —>• a, which is instantiated in 
two different ways, first at type (/3 —> j3) —>■ (j3 —> 13) and second at type (3 —> 13. 
In contrast, A-bound variables are monomorphic, so Xx.xx is ill-typed. 

The syntax of terms and types is 

t, s ::= x | A x.t \ st | letx = sint 

r, v ::= a \ t —> v 

where x and y range over term variables, and a and (3 range over type variables. 
For simplicity, the function arrow —> is the only type constructor. 

1 The work of Hindley (1969) was in type inference for combinatory logic, unlike Milner’s 
type system with let-polymorphism, but ‘Hindley-Milner’ is the name that has stuck. 




To handle let-polymorphism, the context assigns each term variable a type 
scheme a rather than a monomorphic type. A type scheme is a type wrapped in 
one or more V-quantihed variables, with the syntax 

cr ::= r | Vce. a 

Morally, one should distinguish between the ‘universally quantified’ variables in 
type schemes, and ‘existentially quantified’ variables (known as ‘metavariables’, 
‘unification variables’ or ‘holes’) for which solutions are found by unification dur¬ 
ing type inference. However, for this chapter I can conflate the two: variables are 
always bound in type schemes, while metavariables are always free in the context. 

Milner’s typing rules, as presented by Clement et al. (1986) adapted into 
algorithmic form, appear in Figure 2.1. The context A is an unordered set of 
type scheme bindings, with A x denoting ‘A minus any x binding’: such contexts 
do not reflect lexical scope, so shadowing requires deletion and reinsertion. 

Algorithm W is a well-known type inference algorithm for the Hindley-Milner 
system, due to Damas and Milner (1982), and based on the Unification Algo¬ 
rithm of Robinson (1965). Most presentations of Algorithm W have treated the 
underlying unification algorithm as a ‘black box’, but by considering both to¬ 
gether I will show that the generalisation step (used when inferring the type of a 
let-expression) becomes straightforward (Section 2.3). 

Why revisit Algorithm W? As a first step towards a larger goal: explaining 
how to elaborate high-level dependently typed programs into fully explicit calculi, 
as in Chapter 7. Just as W specialises polymorphic type schemes, elaboration 
involves inferring implicit arguments by solving constraints, but with fewer algo¬ 
rithmic guarantees. Pragmatically, we need to account for stepwise progress in 
problem solving from states of partial knowledge. I seek local correctness criteria 
for type inference that guarantee global correctness. 

2.0.1 The occurs check 

Testing whether a variable occurs in a term is used by both Robinson unifica¬ 
tion and Algorithm W. In unification, the check is usually necessary to ensure 
termination, let alone correctness: the equation a = a —>• f3 has no finite solu¬ 
tion because the right-hand side depends on the left, so it does not make a good 
definition for a. 2 

2 Of course, this assumes types are inductively defined: coinductive systems, which allow 
infinitary types as the solutions of such equations, are outside the scope of this thesis. 
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(term t has type scheme a under assumptions A) 


A\~ t:a\ 

x:a G A a>zr Ah t\r 't Ah if :r' A X U {x:t'} h t:r 
Ah x:t Ahtt'-.r A h Xx.t :t' —>• r 


Aht'-.r' a = gen(A, r') A x U {x : a} F t :r 

A h let x — t! in t : r 


a >z t if t is a generic instance of cr (specialising a yields r) 


gen(A, t) 


Vcq l ' el -A t (FI/(t) \ FV(A) = {ai,..., a n }) 
r (FI/ (t) \ FV(A) = 0) 


Figure 2.1: Milner’s typing rules 


In Algorithm VV, the occurs check is used to discover type dependencies just 
in time for generalisation. When inferring the type of let x = t! in t. the type 
of t' must first be inferred, then ‘generic’ type variables, those occurring in t' 
but not the enclosing bindings, must be quantified over. The idea is that type 
variables may be generalised over (and freely substituted) if they are not recording 
a necessary coincidence. For example, a typing derivation for Ay. let x = y in x 
might have {y:a} h y:a for the dehniens. One is certainly not free to generalise 
over a, as this would allow any type to be assigned to x\ On the other hand, a 
derivation for \et x — \y.ym.xx could include 0 h Xy.y.a —> a, and a must be 
generalised over for the whole expression to be well-typed. 

In both unification and type inference, the occurs check is used to detect 
dependencies between variables. The traditional approach of leaving unification 
variables floating in space, without any structure, works for the Hindley-Milner 
system because there are no scoping conditions on candidate solutions for vari¬ 
ables. This will not always be the case, so it is better to expose the structure and 
manage dependencies explicitly. 

In further contrast to other presentations of unification and Hindley-Milner 
type inference, the algorithm I will describe is based on contexts carrying variable 
definitions as well as declarations. This allows the context to record the entire 
result of the algorithm. 
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2.1 A framework for contextual problem solving 


Let me begin by revisiting unification for type expressions with free variables. 
In order to address the problem of solving equations, I must first explain which 
types are considered equal, raising the question of which things a given context 
admits as types, and which contexts make sense in the first place. 

A context 0 is a dependency-ordered list of unknown type metavariables, 
definitions of metavariables and given term variables: 

0 ::= • | 0,a:=t= | 0,a:=T : * | 0,x:cr | 0, 

It is divided into ‘localities’ by the 9 marker, the role of which will be explained 
in Subsection 2.1.2. I write S for a context suffix containing only metavariables. 

Contexts introduce named variables and ascribe properties to them, but the 
properties should first make sense. The rules in Figure 2.3 define the judgment 
0 h ctx, which checks that a context is valid, i.e. that every variable is distinct 
and each property is well-formed for the preceding context. Definitions a:=r : * 
and term variable bindings x : a make sense only if the type r or scheme <7 is 
well-scoped, as verified by the judgment 0 b a: *. 

For example, the context a: *,/3 x: a /3 is valid, while x : a, a: * is not, 
because a is not in scope for x. This dependency-ordering means that entries on 
the right are harder to depend on, and correspondingly easier to generalise. 

Variables must not be duplicated in a context. In the rules, a#0 means a is 
fresh for (does not occur in) 0 . I will usually ignore freshness issues: in practice, 
locally nameless representations (McBride and McKinna, 2004) are sufficient. 

Metavariables definitions induce a nontrivial equational theory on types, as 
given in Figure 2.3. The definitions in a context represent a substitution in 
‘triangular form’ (Baader and Snyder, 2001), that can be applied on demand to 
produce a type or type scheme that contains only unknown metavariables. 

Unification is the problem of finding definitions for metavariables in order to 
make an equation hold. Type inference involves solving unification problems and 
finding a type that makes a typing judgment hold. Solutions to both problems 
should be ‘most general’ in that they should make the least commitment necessary 
to solve the equation or assign a type. In the following subsections, I will make this 
more precise by introducing a general notion of ‘statements’ that can be judged in 
contexts, and defining the permissible ‘information increases’ that move a context 
toward making a statement hold. 
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Term variables 

%y 


Type metavariables 

a, /3 ,7 


Contexts 

0 

:= ■ 0, a: * 0, a:=r : * 0, x:a 

Suffixes 

S 

:= ■ S,a::* E,a:=r : * 

Types 

T, V 

:= a t -3 v 

Type schemes 

a 

:= t Vcc. a 

Terms 

t, s 

:= x A x.t sf letT = sint 

Statements 

J 

:= ctx \ a:* t = v:* \ t:a \ a >- a' 


Figure 2.2: Syntax 


fO is a valid context) 


a#© 

0 b ctx 


a#0 

0 b t: : 


x#0 

0 b a: * 0 b ctx 


■ b ctx 0, a : * b ctx 0, a := r : * b ctx 0, x: a b ctx 0, b ctx 


0 b a: * 


(a is a well-formed type scheme in 0 ) 


0 3 a: * 0 b ctx 

0 b a:* 


0 br:* 0 b v:* 

0 b t —> v: * 


0, a: * b a: * 
0 b Vce. a:* 


0 b t = v : * 


(t and v are equal types in Q) 


0 b t:* 


© b To = Ti : * 0 b Ti = t 2 : * 


0 b t = T : * 


0 b v = r : * 


0 b t 0 = t 2 : 


0 b ctx <d 3 a:=r : * 
0 b a = t : * 


0 b t = r' : * Q \~ v = v' : * 
0bT —y t' = v —> v' : * 


Figure 2.3: Rules for context validity, well-formed schemes and type equality 
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2.1.1 Modelling statements-in-context 

Having introduced contexts, now I will give a general picture of ‘statements-in- 
context’, allowing unification and type inference to be viewed in a uniform setting. 
A statement is an assertion that can be judged in a context, with grammar 

J ::= 

ctx context validity 

a : * well-formed type scheme 

t = v : * equivalent types 

t:a well-typed term 

a y a' generic instantiation of type schemes 

J A J' conjunction of statements 

The rules for valid contexts, well-formed type schemes and type equality are 
given in Figure 2.3. The rules for well-typed terms and generic instantiation of 
type schemes will be given in Section 2.3 (Figures 2.6 and 2.7). The conjunction 
statement has a single introduction rule and admissible elimination rules: 

eh J 0h J' 6 h J A J' 0h J A J' 

0h J A J' 0h J 0b J' 

Each statement J has a corresponding sanity condition, San J, whose truth 
is necessary for J to make sense. For example, the sanity condition for a typing 
statement is that the type is well-formed. Sanity conditions cannot be presup¬ 
posed when writing the rules; rather, care must be taken to ensure them. The 
sanity conditions are given by the following lemma. 

Lemma 2.1 (Sanity conditions). If Q b J then 0 b San J, where 

San ctx i-> ctx 

San(cr:*) i->- ctx 

San (r = v) i->- r : * A v :* 

San (t:a) i->- a:* 

San (ay a') i-> a:* A a':* 

San (J A J') i-> San J A SanJ' 

Proof. By structural induction on derivations. The sanity condition for the ctx 
statement is uninformative, as it merely says that 0 b ctx implies itself. □ 

Sanity conditions capture the requirements for a statement to be ‘meaningful’, 
before one can ask whether it is ‘true’ (Martin-Lof, 1996). 
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(9 is a metasubstitution from 0 O to ©fy 


9 : 0 O C 0i 


0 : 0 O C 0i 0ihr:* 
[] : • ES (0,r/a):0 o ,a:*C0i 


0:©oE©i 0i h r = 9v:* 
( 9,r/a ) : 0 o ,a:=u :*C0, 


9 : 0 O t= ©i 

9 : 0 O , x:a □ ©i ,x:9a,E 


9 : 0 O C 0i 

0:0 o, C ©1 9 2 


6 = 0L0Q □ 0! (9 and 9' are equivalent metasubstitutions from 0 O to ©i ) 

6 = 9'-.Q 0 QQ i ©i F r = r': * 

■ = ■:•□©! (0, r/a) = (0', r'/a ) :0 O ,«:*E© 1 

9 = 9': ©o C 0i ©i F t = 0 U: * ©i F t = t 7 : * 

(0, r/a) = (0/ t'/o:) : ©o, a : * □ ©i 

0 = 0':0 Q □ ©i 0 = 0':0 o C©i 

6> = 0 / :0 o ,r:cr □ 0i,x:0cr, S 0 = 0 / :0 O 9 C ©i 9 S 


Figure 2.4: Metasubstitutions 

2.1.2 An information order for contexts 

In order to describe algorithms that make incremental progress by modifying the 
context (substituting for variables or turning unknowns into definitions), I must 
specify what constitutes progress. This amounts to giving an ‘information order’ 
on contexts, so that increasing in the order makes a context ‘more informative’, 
i.e. more statements hold. 

Let 0 O and ©i be valid contexts. An information increase or metasubstitution 
from ©o to ©i is a finite map 0 from metavariables in 0 O to well-formed types 
in ©i, that respects the structure and dependency order of 0 O . Figure 2.4 gives 
rules for the judgment 0 : 0 O E ©i that explains when 0 is a metasubstitution. 
This can be understood by looking at the form of 0 O in each rule. If it is empty, 
then ©i may contain metavariable declarations H but no fixed structure. If the 
last entry in 0 O is a metavariable, then 0 must give a well-formed type in ©i to 
substitute for the metavariable, which should agree with the existing definition 
(if any). If the last entry is a term variable or 9 marker, then ©i must have 
the same structure. Recall that a context suffix S contains only metavariable 
declarations, not term variables or 9 markers, so it may always be added without 
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changing the underlying structure. 

Metasubstitutions act on types and statements in the obvious way, extending 
the action on variables 


9 a i— y t if r/a e 9 

homomorphically on syntax. The identity metasubstitution l : 0 □ 0' where 0' 
includes all the variables of 0, usually just written © □ ©', replaces each variable 
with itself. A finite list of type-metavariable pairs, such as [r/a], represents a 
metasubstitution that is the identity except where specified. 

Equivalence of metasubstitutions, written 9 = O' : 0 O C 0i or simply 9 = 9' 
when the contexts are obvious, means that the corresponding types are equal, as 
shown in Figure 2.4. 

Stable statements 

Intuitively, substituting a type r for a metavariable a should not be able to falsify 
any existing equations. More generally, making contexts more informative should 
preserve derivability of judgments. What is it about the design of the deduction 
system that ensures this? 

A statement J is stable if it is preserved by metasubstitution, i.e., if 

©o b J and 9 : ©o E 0i =£■ ©i \~ 9 J. 

That is, a simultaneous substitution on syntax extends to apply to derivations 
of stable statements: information increase is really the extension of simultaneous 
substitution from variables-and-terms to declarations-and-deri vat ions. 

As context entries ascribe properties to variables, so statements ascribe prop¬ 
erties to expressions. Each entry corresponds directly to a statement: a: * and 
x:a are both entries and statements, while a : = r : * corresponds to a = r:*. A 
context entry causes the corresponding judgment to hold, that is, the rule 

Q 3 J 

- LOOKUP 

©b J 

is admissible. Compare this to the variable rule of a type theory: as variables 
embed in terms, so contextual properties of variables embed in judgments. 

There is a systematic technique to ensure the stability of statements by con¬ 
struction of the deduction system: the only rules using information from the 
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context should correspond to LOOKUP, asserting that an entry in the context 
holds as a statement. It is then enough to check that recursive hypotheses occur 
in strictly positive positions, so they are stable by induction. 

Lemma 2.2 (Stability). If Qo b J then J is stable. 

Proof. By structural induction on derivations. □ 

Stability means that information increases are closed under composition, where 
0 2 • 0 1 is defined by applying 0 2 to every type in 0\. 

Lemma 2.3 (Category of contexts). Contexts form a category with information 
increases as morphisms. In particular, 

6 l : 0 O □ ©i and 9 2 : ©i □ © 2 => 0 2 ■ 0 i : © 0 □ © 2 . 

Proof. It is straightforward to verify that composition is associative and has iden¬ 
tity i. To show closure under composition, proceed by induction on 0 O . 

If 0o is empty, then 9\ is trivial, so 0 2 ■ 9\ is trivial. Moreover 0i consists only 
of metavariable declarations, so the same applies to © 2 . 

If 0 O = 0' o , a : * then 9 1 = 9[, r/a where 9\ : 0' o C ©i and ©i h r: *, Now 
induction gives 0 2 ■ 9\ : ©(, C 0 2 and 0 2 h 0 2 t : * by stability, so 0 2 ■ 9\ : © 0 E ©2 
since 0 2 ■ (9i,t/cx) = ( 0 2 ■ 9f), {9 2 T)/a. The case where 0 O ends with a defined 
metavariable is similar, using stability of the equality statement. 

If ©o = ©o, x : a then ©! = ©' x , x: 9\ a, §|i and 9i : 0' o C ©^ Similarly 0 2 = 
©2, x: [0 2 ■ 9\) a, S 2 and 0 2 : ©^ C ©' 2 . Now induction gives 0 2 ■ 9\ : ©q C ©' 2 . □ 

Preserving structure in the context: the , separator 

The unification and type inference algorithms given later will exploit the decla¬ 
ration order in the context, moving declarations left as little as possible. Thus 
the rightmost entries will be the ‘most local’. Moving a declaration left (making 
it ‘more global’) reduces the choice of solutions, but increases the visibility of the 
variable, widening its scope. The ordering constraints will be particularly useful 
for implementing type inference for the let-expressions, in order to generalise over 
‘local’ type variables but not ‘global’ variables. 

A locality is a section of a context © that contains only metavariables, so term 
variables and the marker , separate localities. The definition of metasubstitution 
9 : ©o Q ©i makes the localities of 0 O and ©i correspond, so that declarations 
in any prefix of 0 O can be interpreted over the corresponding prefix of ©i. Thus 
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if 9 : ©o 9 0'o E © then © = ©i , ©^ where 6>|© 0 : 0 O E ©i- (Here 6>|© 0 is the 
metasubstitution 9 restricted to the metavariables in 0 O .) 

As a consequence, moving a metavariable ‘left of a , separator’, into a new 
locality, is an irrevocable commitment. For example, 0 9 a : *, ©' □ 0, a : * 9 ©' 
holds but the converse direction does not. 

The 9 separators do not affect the statements that are provable in a context, 
however: © 9 ©' b J if and only if 0, ©' b J. 

Just as with 9 separators, given variables in the context are preserved by meta¬ 
substitution, and their type schemes must be updated appropriately. It would be 
possible for the definition of 6 : 0 O E © x to require ©i to assign a term variable 
x all the types that 0 O assigns it, but allow x to become more polymorphic and 
acquire new types. For example, the identity ‘information increase’ 

0, x:r —>• r E 0, x: Va. a —> a 

could be permitted. This notion certainly retains stability: every variable lookup 
can be simulated in the more general context. However, it allows term variables 
to be assigned arbitrarily generalised type schemes, which are incompatible with 
the known and intended value of those variables. As Wells (2002) points out, 
Hindley-Milner type inference is not in this respect compositional. He carefully 
distinguishes principal typings, given the right to demand more polymorphism, 
from Milner’s principal type schemes and analyses how the language of types 
must be extended to express principal typings. 

2.1.3 Constraints: problems at ground mode 

I have described the information-increasing steps that a problem-solving algo¬ 
rithm can take, but how are problems themselves represented? Given any state¬ 
ment J for which the corresponding sanity conditions of Lemma 2.1 hold, it is 
reasonable to ask for the least information increase needed to make J hold. 

Formally, a constraint problem is a pair of a context ©o and a statement J, 
where ©o F San J. A solution to such a problem is then a context ©i and an 
information increase 9 : © 0 E 0 X such that ©1 h 9 J. Such a solution is minimal 
if, for any other solution 9' : 0 O E ©', there exists a metasubstitution ( : ©' C ©i 
such that 9' = C ■ 9 (say 9' factors through 9 with cofactor £). 

In this setting, a unification problem is a constraint problem where J is an 
equation, that is, a pair of a context 0 O and an equation r = v, where 0 O hr:* 
and ©0 h v : *. A solution to the problem (a unifier ) is given by a context ©1 and 
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a metasubstitution 9 : 0o □ ©i such that 0 1 h 6 t = 9 v A minimal solution 
is a most general unifier. 

Information increase allows variables to become more informative either by 
definition or by substitution. The algorithms presented here exploit only the 
former, always choosing solutions of the form 0 O E ©i- However, I will show the 
solutions are minimal with respect to arbitrary information increases: making 
progress by definition alone is enough to capture all possible solutions. 

Stability permits sound sequential problem solving: if 9 0 : 0o E^ ©i solves J 
and 6\ : ©i jZ 0 2 solves 9 0 J' then 6 fi • 9 0 : © 0 E 0 2 solves J A J'. Perhaps 
more surprisingly, composite problems acquire minimal solutions similarly. This 
allows a ‘greedy’ minimal commitment strategy for problem solving . 3 

Lemma 2.4 (The Optimist’s lemma). If 9 0 : 0 O E ©i is a minimal solution of 
J and 9\ : ©i E © 2 is a minimal solution of 9 0 J' then 9\ ■ 9 0 : 0 O HE ©2 is a 
minimal solution of J A J'. 

Proof. Any solution £ : 0 O E © to (0 O , J A J') must solve (0 O , J ), and hence 
factor through 9 0 : ©o E ©i- But its cofactor solves (©i, 9 0 J'), and hence factors 
through 9\ : ©i E © 2 . □ 

I will use this lemma to prove that the unification algorithm delivers most 
general unifiers. It also expresses the underlying reason why type inference gives 
principal solutions, although a more general result is needed there, because state¬ 
ments have outputs and the second statement may depend on the first. 

This sequential approach to problem solving is not the only decomposition 
justified by stability. The account of unification by McAdam (1998) amounts to 
a concurrent, transactional decomposition of problems. One context is extended 
by multiple substitutions, which are then unified to produce a single substitution. 

Another reassuring property of problem solving is that minimal solutions are 
well-defined up to isomorphism. A metasubstitution 6 : © E ©' is an isomorphism 
if there exists 9~ l : O' E 0 such that 9~ l ■ 9 = t and 9 ■ 9~ x = i. The following 
lemma allows the contexts ©o and ©i to be replaced with the isomorphic 0 and 
O', while retaining minimality. 

Lemma 2.5 (Isomorphism lemma). Suppose 0, O', 0 O and ©i are contexts, J is 
a well-formed statement in 0 O and ( : 0 E ©o and (' : ©i C ©' are isomorphisms. 
If 9 : Q o^©i is a minimal solution of J then (f ■ 9 ■ f : 0 C ©' is a minimal 
solution of C -1 J ■ 

3 The ‘optimistic optimisation’ of McBride (1999). 
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Proof. Composition gives that £' • 9 ■ ( : 0 □ 0' is a metasubstitution, and since 
0i h 9 J we have 0' h (,' (9 J ) by stability (Lemma 2.2), so 0' I - ((' ■ 9 ■ () (C _1 J )• 
Hence Cf ■ 9 ■ ( is a solution of £ -1 J. 

To see that it is minimal, suppose 9" : 0 C 0" is such that 0" b 9" (£ -1 J). 
Now 9" ■ C _1 is a solution of J, so by minimality of 9 there must be some (" such 
that (" : 0i □ 0" and (" - 9 = 9" ■ £ -1 . Hence ((" ■ ( /_1 ) • (£' • 9 ■ () = 9" so the 
required cofactor is (" ■ ( ,_1 : O' O Q". □ 


2.2 Unification for the syntactic equational the¬ 
ory 

Having set the scene, I will now present the unification algorithm itself. The al¬ 
gorithm starts by structurally decomposing a constraint into multiple constraints 
on variables, which can be solved sequentially (by the Optimist’s lemma). Each 
remaining constraint is either an equation between two variables (a flex-flex con¬ 
straint) or between a metavariable and another type (a flex-rigid constraint). 
Either way, it is solved by moving through the context from right to left (most 
local to most global), updating the constraint or context appropriately. 

For example, consider the context a : f3 : *,a' := f3 : *,7:* and problem 
a —>• /? = a' —>• (7 —>• 7). This equation decomposes into two constraints on 
variables, a = a' and /3 = 7 —>• 7. The first is solved thus: 


a : *, 


a' := (3, 

7 : *. [a = a' 

a : *, 

£:*, 


[a = a'], 7 : * 

a : *, 

#:*, 

[a = p], 

a' -=/ 3 , 7 : * 

a : *, 

(3 :—a , 

a':—/?, 

7 : >1= 


To solve a = a', the algorithm ignores 7 since it does not occur in the 
constraint, moves past a' by updating the constraint to a = / 3 , then defines 6 . 

Solving the flex-rigid constraint = 7 —> 7 requires 7 to be moved back 
through the context, since it occurs in the constraint but cannot be instantiated: 


a : *, 

[3 :=«, 

of 


a : *, 

(3 :—a. 

of 


a : *, 

j 3 :=a, 

[7 

■ *\0 = y 

a : *, 

[7 : * | cr = 7 —> 7], 


-a, 


7 : *1 \P = 7 ^ 7] 
[7 : * | /? = 7 —> 7] 
7], a':=£ 
a':=fl 


/3 :=«, 


a':=f3 
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Here the algorithm ignores a', moves past the definition of 0 by updating the 
constraint to a = 7 —>• 7 , then dehnes a after pasting in 7 . In general, when 
solving an ‘flex-rigid’ equation between a metavariable and a type, the algorithm 
must accumulate the type’s dependencies as it finds them, performing the occurs 
check to ensure a solution exists. This is how variables move outward through 
localities, acquiring a more global relevance. 

The unification algorithm is formally defined by the rules in Figure 2.5. Each 
inference rule can be read clockwise from the bottom-left: the inputs to the rule 
determine the inputs to the first premise, then the outputs from the first premise 
determine the inputs to the second premise, and so on, until the outputs from all 
the premises determine the outputs of the conclusion. 

The unify judgment 0 O h r e u : * H 0j means that given inputs 0 O , r and 
v, unification succeeds with solution 0 O C © 1 . The inputs must satisfy the sanity 
conditions 0 O F t : * and 0 O F v : *. Symmetric variants of the INST and define 
rules have been omitted. 

The instantiate judgment 0 O H h a e r : * H 0| means that given inputs 0 O , 
5, a and r, instantiating a with r succeeds, yielding solution 0 O C © 1 . The idea 
is that the bar (|) represents progress in examining context elements in order, 
and 5 contains exactly those declarations on which r depends. Formally, the 
inputs must satisfy the following conditions, where the set fmv(r) records those 
metavariables occurring free in type r. 

Definition 2.1. The quadruple (©o, 5, cc, r) satisfies the input conditions if 

• ©o F a: * where a: is a metavariable, 

• 0 O ,S hr:* where t is not a metavariable, and 

• 5 contains only metavariable declarations 0 :* with 3 E fmv(r). 

The main point of these conditions is to ensure that S contains only genuine 
dependencies of t, so moving H back in the context will not sacrifice generality. 

Observe that no rule applies to deduce 

©0, a:*|Sbo: = T:*H0i with a E fm v(t), 

where the algorithm fails. This is an occurs check failure: a and r cannot unify if 
a occurs in t, and t is not a variable. Given the single type constructor symbol 
(the function arrow —>•), there are no failures due to rigid-rigid mismatch, but 
adding these will not significantly complicate matters. 

The unification algorithm is implemented in Appendix A.2 (page 200). 
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(unifying r with v in 0 O results in 0 ly ) 


©o h r = v : * H 0! 


0 o b To = vq : * H 0 i 0 i b Ti = v\ : * H 02 

0o b (to fi) = (vo *© ^i) : * H 02 
t non-variable 0 O | • b a = r : * H 0 


DECOMPOSE 


0 O b a = t : * H 0 i 


a ^ P 


®,a:* a = a : * Q,a:* 0, cc: * b a = /3 : * H 0,o:= 

©o l~ [t/t] a = [r/7] /3 : * H 01 

©o, 7 : =t : * b a = /3 : * H Q u *$:=r : * 

0 O b ct = /3 : * H ©i a ^7 /3 ^ 7 


© 0 , 7 :* b a = /? : * H © 1 , 7 :* 


0 o b a = p : * H 0 i 

0 O , x:a b a = /3 : * Oi,x:cr " 


0 O b a = (3 : * H 0i 

©09 b a = 13 : * H ©19 


- SKIP-SEMI 


| 0 o | 5 bo ; = T :*- l 0 i | (instantiating a with t in 0 O , S results in Qi) 

a £ fmv(r) 


- INST-DEFINE 


©o, a:*|SbaEr : * H 0 O , S, a r : * 

©o, S b [t;//?] a = [1;//?] t : * H ©i 

©o ,/3:=v : * |j|§:lr a = r : * H Qi,j3:=v : * 

0 O |/3:*,Sba; = T:*H0i a ^ ft /3 £ fmv(r) 
0 O ,/l:*|SbaET: *H0i 

0 o |Sbo; = T:*H©i 0^/3 /3 ^ fmv(r) 


- INST-DEPEND 


©o, /3 : * | 5 b a = t : * H © 1 , (3 : * 

0 o |Sbo; = r:=t=H0i 
© o , x:a |5bo; = r:*H0i,x:cr 


INST-SKIP-TY 


INST-SKIP-TM 


0 o |SbQ; = T:*H0i 
-—- INST-SKIP-SEMI 

©0 9 |S b a e t : * H ©i. 


Figure 2.5: Algorithmic rules for unification 
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2.2.1 Correctness of syntactic unification 

The contextual problem-solving discipline I have introduced allows soundness to 
be linked with generality, showing that unification produces minimal solutions. 
Lemma 2.6 (Soundness and generality of unification). 

(a) If 0 O b r = v : * H 0i then © 0 E ©i is a minimal solution of r = v. 

(b) // 0 O | S h a = r : =k H ©i then 0 O , S □ ©! is a minimal solution of a = r. 

Proof. By induction on the structure of derivations. The key idea is that the type 
variables of 0 O and ©i are the same, and whenever 9 : 0 O jZ ©' is a solution, 
the definitions made in ©i must hold as equations in ©' for the problem to be 
solved, so 9 can be rearranged to produce the necessary cofactor ( : ©i □ ©'. For 
details, see Appendix D.l (page 236). □ 

A lemma about the occurs check is needed for completeness of unification. 

Lemma 2.7 (Occurs check). Let a be a metavariable and r a non-metavariable 
type in 0 such that a e fmv(r). There is no context ©' and metasubstitution 
9 : © jZ ©' such that ©' h 9a = 9 t : 

Proof. Suppose otherwise. By expanding definitions in ©' we have a type con¬ 
taining no defined metavariables that is equal to a proper subterm of itself, but 
induction on the definition of equality shows that this is impossible. □ 

Exposing the structure underlying unification makes termination of the al¬ 
gorithm evident (McBride, 2003). Each unification or instantiation step either 
shortens the overall context, shortens the uninspected context left of the bar (for 
instantiation) or preserves the context and decomposes types. 

Lemma 2.8 (Completeness of unification). 

(a) If 9 : ©o |Z ©', 0 O |- v : * A r: * and ©' h 9v = 9 t : *, then there is some 
context ©i such that 0 O h v = r : * H ©!• 

(b) Moreover, if 9 : ©o,S □ ©' is such that ©'I - 9 a = 9r : * and the input 
conditions (Definition 2.1) are satisfied, then 0 O | H b a = r : * H Q i. 

Proof. Since the algorithm terminates, it suffices to show that it covers every case 
such that a solution can exist. Each step preserves solutions: if the equation in a 
conclusion can be solved, so can those in its premises. The only omitted case is 

©o,a::* |Sba: = T:*H©i with a G fmv(r), 

but Lemma 2.7 implies that this has no solutions. □ 
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(term t has type scheme a in Q) 


9 b t:a 

0 b t:r v 

0 9 x:a 0 b ctx 0,x:r\~t:v 0 b s:t 

0 h x:a 0b A x.t-.r^v ©hi ts:v 


0 1 ~ s:a 
Q,x:a b t:a' 

0 b let x = s in t: a' 


0 b f.Va.a 

0, or.* b t: a 0 b r: * 

©b t:Wa.a 0 b t:[r/a}a 


© b t:r 
© b t = v : * 
0 b t:v 


Figure 2.6: Declarative rules for type assignment 


0 b a >- cb] 

0 b t = v : * 
0 b r >- v 


(a is 

a fmv(cr) 

0, a : * b a >- a' 

0 b a >- Ma. a' 


ore general than a' in 0 ) 

0b t:* 

0 b [t/cc] a >- v 
0 b Vcc. a >- v 


Figure 2.7: Generic instantiation for type schemes 


2.3 Type inference with generalisation made easy 

The deduction rules for the typing statement t : a are given in Figure 2.6. Type 
inference involves making this statement hold, but unlike unification, the type 
should be an output of problem-solving along with the solution context. The def¬ 
inition of constraint problems in Subsection 2.1.3 is insufficiently general. Instead, 
each parameter in a statement has a mode , either ‘input’ or ‘output’. 

A type inference problem consists of a context 0 O and a term t; a solution is a 
metasubstitution 9 : 0 O C 0 X and a type r such that ©i b t : r. Such a solution 
is most general or minimal if any other solution {O' : 0 O Q ©', v) factors through 
it with cofactor £, such that ©' b v = ( r : *. 

Similarly, a type scheme inference problem consists of a context 0 O and a 
term t] a solution is a metasubstitution 9 : 0 O b ©i and a scheme a such that 
©i b t : a. Such a solution is most general or minimal if any other solution 
{O' : 0 O G ©', a') factors through it with cofactor ( such that 0' b ( a >- a'. 

Here a >- a' is the generic instantiation relation, defined in Figure 2.7, meaning 
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that any type which is an instance of a' is also an instance of a. 

Type schemes arise by quantifying a context suffix (a list of type metavari¬ 
ables) H over a type r, written VH.r and defined by 

V • .T !->• T 

V(a:*,H).r ^ Va.(VS.r) 

V(a:—v : *, H).t i->- [u/a] (VH.t) 

Any scheme a — Vcq b r can be viewed in this way, using the suffix cq: A . 
Lemma 2 . 9 . ©bf:(VH.r) if and only if 0,Hb t:r. 

Proof. Straightforward induction on 5. □ 

2.3.1 The Generalist’s lemma 

Recall that 9 markers divide the context into localities. In the type inference 
algorithm, the metavariables that can be generalised are exactly those in the 
current locality. This relies on the following lemma, which states that a minimal 
solution to a type scheme inference problem can be found from a minimal solution 
to a type inference problem. 

Crucially, a substitution for variables in a locality cannot depend on variables 
in a ‘more local’ one: for example, [/3/ai, (3/f3\ : a: * 9 /3: * C ■ , d: * is forbidden. 
This allows any 6 : 0 $ 5 C 0' $ H' to be restricted to variables in 0, so that 
6\ e : 0 C 0'. 

Lemma 2.10 (The Generalist’s lemma). If 9 : 0 O 9 C 0^5 is a minimal solution 
of the type inference problem for t with output t, then 9 : 0 O Q 0 i is a minimal 
solution of the type scheme inference problem for t with output VH.r. 

Proof. If 9 : ©09 C ©i 9 S then 9 : 0 O Q ©i by definition of C. Furthermore, 
0i b t:(VS.r) holds iff 0i 9 5 h Ct by Lemma 2.9. 

For minimality, suppose 9' : ©o C 0 ; is an information increase and Vcq*. v is a 
scheme such that 0' h t:Va 7 *. v. Then 0', cq: * 1 b t:v. Now 9' : ©09 C 0', a^:* 1 
and 0 ' 9 m : * 1 b t : v, so by minimality of the hypothesis there is a cofactor 
C : 0i 9 H □ 0' 9 obt#/ ; such that 9' = ( ■ 9 and 0', af T* * b (t = v : *. Then 
C|©i : ©i E ©', 9' = C|Gi • 0 and 0' b Cl©! (VH.r) b- V« 7 l . v as required. □ 

2.3.2 Transforming type assignment into type inference 

The typing rules in Figure 2.6 do not directly lead to a type inference algorithm, 
as they permit unrestricted generalisation and instantiation of type schemes. To 
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0 I - t\T 


<d 3 x:cr 0h(i)-T 


0;Bh s:v 0, x: (VE.v) \~ t :r 
0 h let x = s in t: r 


Figure 2.8: Transformed rules for type assignment 

resolve this, an equivalent system (assigning types rather than type schemes) is 
given in Figure 2.8, where instantiation occurs only at variables, and generalisa¬ 
tion at let-bindings. This transformation is well known: a clear presentation is 
given by Clement et al. (1986) resulting in the rules of Figure 2.1. 

From the transformed rules, an algorithm can be constructed to match. To 
convert a rule into algorithmic form, proceed clockwise starting from the inputs 
to the conclusion. For each premise, ensure that the problem inputs are fully 
specified (by the inputs to the conclusion and the outputs of previous premises), 
inserting metavariables to stand for unknown inputs. Instead of pattern matching 
on problem outputs, ensure there are schematic variables in output positions, and 
reintroduce unification constraints as necessary. 

The type inference judgment 0 O F t : r H 0i and the scheme inference 
judgment 0 o Ff:<rH0i are defined by the rules in Figure 2.9. As they are 
structural on terms, they yield a terminating algorithm. The Optimist’s lemma 
means that sequential solution of problems delivers a minimal solution, and the 
Generalist’s lemma makes it easy to reduce type scheme inference problems to 
type inference problems. 

The A-rule now generates a metavariable for the argument type. The rule for 
application assigns types to the function and argument separately, then inserts 
an equation with a fresh name for the codomain type. 

The type inference algorithm is implemented in Appendix A.3 (page 202). 

2.3.3 Correctness of type inference 

Since the algorithmic rules correspond directly to the transformed declarative 
system in Figure 2.8, it is easy to prove soundness, completeness and generality 
of type inference with respect to this system. 
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0 O I - t : a H ©i 


©o I - t : r H ©i 


(term t in context 0 O has inferred scheme a in context ©ij 
©09 h t : t H ©i 9 5 


n u+ INFER-GEN 

©o h t : (Vs.t) H ©i 

(term t in context 0 O has inferred type t in context ©ij 
x-.Nai 1 . v) e ©o 

7 INFER-VAR 


©o F x : v H ©o,«;: 

© 0 ,a::*,a;:a: h t : t H ©i, x:a, S 

- INFER-LAM 

©o I - A x.t : a —>■ r H ©i, S 

©o b 5 : v H ©i ©i h t : v' H 0 2 ©2, a:* Hue a : * H © 3 

©o I - s ^ : a; H ©3 

©o h 5 : cr H ©i ©i, x: a - h t : t I 0 2 , x: a, S 


©o leta; = sint : tH ©2,S 


- INFER-LET 


Figure 2.9: Algorithmic rules for type inference 

Lemma 2.11 (Soundness and generality of type inference). If 0 O b t : r H ©i, 
then ©o E ©i is a minimal solution to the type inference problem for t with output 
t. Similarly, if Qo h t : a H ©i then ©o E ©i is a minimal solution to the type 
scheme inference problem for t with output a. 

Proof By induction on derivations, using the Optimist’s lemma (2.4) and Gen¬ 
eralist’s lemma (2.10). For details, see Appendix D.l (page 237). □ 

Lemma 2.12 (Completeness of type inference). 

(a) If (©o, t) is a type inference problem with solution (0:0 0 G ©', v), then 
©o b t : t H ©i for some ©i and r. 

(b) If (0 O , t ) is a scheme inference problem with solution (6 : 0 O G O', a'), then 
©o h t : a H ©i for some ©i and a. 

Proof. By induction on the derivation of O' h t: v or ©' h t: a' in the transformed 
declarative system of Figure 2.8. Each case corresponds directly to an algorithmic 
rule. For details, see Appendix D.l (page 238). □ 
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2.4 Elaboration, zipper style 


Elaboration is a step beyond type inference, where instead of merely generating 
a type corresponding to the source term, a representation of the term in a more 
explicit calculus is generated. This might seem excessive for the simple Hindley- 
Milner system, but for more complex type systems (particularly those involving 
dependent types) the distinction is helpful. In Chapter 7,1 will discuss elaboration 
of a Haskell-like language. Here, to introduce the idea of elaboration, I show how 
to elaborate Hindley-Milner terms into explicitly-typed predicative System F. 
This algorithm is implemented in Appendix A.4 (page 204). 

The grammar of System F terms is 

e ::= x \ Xx:a.e | A a:*.e \ ee' \ er 

where A-bound variables have type annotations, and type abstraction and ap¬ 
plication are explicit. The type system is standard, and hence omitted; it is 
essentially a syntax-directed version of the declarative system in Figure 2.6. 

So far in this chapter, the context structure has carried the ‘linguistic’ context 
of term variables and type metavariables, but the type inference algorithm has 
separately managed the ‘syntactic’ context (the structure of the term). Variable 
bindings and the , marker are vestiges of the syntactic context: a variable rep¬ 
resents the fact that type inference is taking place under a A- or let-binding, and 
a 9 marker represents ‘being under a let-definiens’. Let me take this idea to its 
natural conclusion, identifying the syntactic and linguistic contexts into a single 
data structure that represents progress through a type inference problem. 

Huet (1997) taught us how to use a ‘zipper’ data structure to represent a 
position in a tree, such as a term. The path to the current location is represented 
as a list of layers, where each layer corresponds to choosing a single branch at 
a node, and stores the subtrees rooted at the other branches. McBride (2001) 
observed that the type of the zipper can be computed by differentiation, and 
further refined the structure to represent left-to-right progress through a term 
(McBride, 2008). Terms ‘to the left’ of the current location have been elaborated 
to a typed System F term, while those ‘to the right’ have not yet been visited. 
Thus the syntax of layers is given by 

£ ::= []t | (e:r)[] | A x:r.[] | leta:=[]int | let a;: a = e in [] 

where a hole [] represents the current position. Contexts are adapted to include 
layers rather than variables or , markers: 

0 ::= • | 0, a: * | 0, a: * := r | 0, i 
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0 l X 

H- 

0, aj 


t XOij j 

t if 0 4 x:Vaj j . t 

0 l st 

1-4 

e.D* 


l S 


0 i A x.t 

H- 

0, cc: 

*, Xx:a.[] It 


0 4- let x — s in t 

H- 

0, let 

X — 

[] in t l s 


0, Ax:n.[], 5 


t e:r 

i-4 

0,5 

t \xw.e : v — > t 

0, let x= [] in t, 5 


t e: t 

i-4 

0, let x: VS.t 

= AS.ein [] It 

0, let x:a = e' in [], 


t e\T 

i-4 

0,5 

t (Aaucr.e) e' : r 

0,[]f,S 


t e: r 

i-4 

0,5, (e:r)[] 

it 

0,(e':u)[],S 


t e: t 

H4 

0' 

where 0, 5, /3: 

t e' e: £ 

*h t; e r 4 |3 : H 0' 


Figure 2.10: Elaboration as state-transformation 


Now that 0 represents the entire context of an elaboration problem, elabo¬ 
ration can be implemented tail-recursively as an state-transforming automaton. 
Figure 2.10 shows the elaboration algorithm. It is divided into two modes: 

• The ‘downwards’ mode 0 | i takes a context and a source term which is 
being elaborated. If it is a variable, control switches to the ‘upwards’ mode, 
otherwise it moves into an appropriate subterm by extending the context. 

• The ‘upwards’ mode 0fe:r takes a context and an elaborated System F 
term with its type. It examines the context to move outwards, refocus on 
the next subterm to elaborate, then switch back to downwards mode. 

The algorithm should be invoked in downwards mode with the empty context 
and the original term to be elaborated. Eventually, if the term is well-typed, the 
upwards mode will run out of layers and terminate with the elaborated version 
of the term and its type. 

This explicit representation of partial progress through an elaboration problem 
is very useful when constraints cannot always be solved immediately, as in a 
dependently typed setting. Elaboration is no longer a left-to-right march through 
the term structure, but may involve back-and-forth refocusing as the elaborator 
finds places where progress can be made. This is the basis of the implementation 
of elaboration in Epigram. 
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2.5 Discussion 


In this chapter, I have given an implementation of Hindley-Milner type inference 
involving all the same steps as Algorithm VV, but not necessarily in the same 
order. In particular, the dependency panic that seizes W in the let-rule becomes 
an invariant that the unification algorithm maintain a well-founded context. 

The algorithm is presented as a problem transformation system locally pre¬ 
serving solutions, hence finding a most general global solution if any solutions 
exist at all. Accumulating solutions to decomposed problems is justified simply 
by stability of solutions on information increase. The discipline of problem solv¬ 
ing established here is happily complete for Hindley-Milner type inference, but 
in any case couples soundness with generality. 

Maintain context validity, make definitions anywhere and only where there 
is no choice, so the solutions you find will be general and generalisable locally: 
this is a key design principle for elaboration of high-level code in systems like 
Epigram and Agda, and bugs arise from its transgression. The account given 
here of ‘current information’ in terms of contexts and their information ordering 
provides a principled means to investigate and repair these troubles. 

There is, however, some way to go. Algorithm W is a conveniently structural 
type inference process for ‘finished’ expressions in a setting where unification is 
complete. Each subproblem is either solved or rejected on first inspection—there 
is never a need for a ‘later, perhaps’ outcome. As a result, ‘direct style’ recursive 
programming is adequate to the task. If problems could get stuck, how might an 
algorithm abandon them and return to them later? By storing their context , of 
course! In Chapter 4, I will take exactly this approach to deal with higher-order 
unification problems. 

First, though, I will extend the framework in another direction: handling units 
of measure with the equational theory of abelian groups. Variable dependency 
becomes more subtle in the presence of a nontrivial equational theory, and so 
maintaining a well-founded context (in order to make generalisation straightfor¬ 
ward) is even more crucial. 
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2.5.1 Related work 

The idea of assertions consuming an input context and producing an output 
context goes back at least to Pollack (1990). Nipkow and Prehofer (1995) use 
unordered input and output contexts to pass information about Haskell typeclass 
inference, with a conventional substitution-based presentation of unification. 

The work of Dunheld and Krishnaswami (2013) on higher-rank polymorphism 
in a bidirectional type system, based on earlier work by Dunheld (2009), uses well- 
founded contexts that contain existential type variables (amongst other things). 
They rely on a notion of context extension in a similar way to my definition of in¬ 
formation increase between input and output contexts, and while their treatment 
of unification is different (since they are dealing with subtyping for higher-rank 
polymorphism, rather than let-generalisation) there are some similarities with the 
approach I have described. 

An alternative approach to generalisation, used in some ML implementations 
for the sake of efficiency, involves assigning numeric ‘ranks’ to type variables 
based on the number of bindings they are introduced under, then generalising 
over variables whose rank is sufficiently large. Remy (1992) implemented an 
algorithm based on counting let-bindings as part of the OCaml typechecker, and 
Kiselyov (2013) gives a clear explanation of Remy’s algorithm which relates it to 
region-based memory management. Kuan and MacQueen (2007) formalised and 
compared approaches that count let- and A-bindings; they attribute the idea for 
counting A-bindings to Damas (1984). The algorithm I described manages ranks 
implicitly, by representing type variables in an ordered context, in which the ? 
marker corresponds to increasing the rank. 
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Chapter 3 


Unification and type inference for 
units of measure 


In the previous chapter, I described a ‘problem solving’ rationalisation of syn¬ 
tactic unification and Hindley-Milner type inference that provides a more refined 
account of dependency analysis. Term and type variables live in a dependency- 
ordered context. Problems are solved in small steps, each of which is most general 
and involves minimal extra dependency. This makes let-generalisation particu¬ 
larly easy: simply ‘skim off’ generalisable type variables from the end of the 
context, as nothing can depend on them. 

I now move on to consider one of the many extensions of the Hindley-Milner 
system, namely units of measure in the style of Kennedy (1996a,b, 2010). My 
approach to type inference gives a clearer account of the subtle issues surrounding 
generalisation in the presence of a nontrivial equational theory on types. This 
chapter is based on work presented at TFP 2011 (Gundry, 2011). A Haskell im¬ 
plementation of the unification algorithm described here is given in Appendix B. 

Consider this Haskell function, traditionally of type Float —> Float: 

distanceTravelled t = velocity * t+ (acceleration * t* t) / 2 
where {velocity = 2.0; acceleration = 3.6} 

Kennedy (1996b) shows how to check units of measure for such terms: with 
velocity and acceleration annotated with their units (m * s -1 and m*s -2 ), the 
system could infer the type Float(s) —>• Float(m) for the whole function. Type 
inference relies on unification, but units need a more liberal equational theory 
than syntactic equality, asm*s“hs should mean the same thing as m. Kennedy 
uses the theory of abelian groups. He has introduced units of measure with 
polymorphism into the functional programming language F# (Syme, 2010). 



3.0.1 A troublesome example 

Algorithm VV relies on dependency analysis for let-generalisation. Using the 
occurs check to identify generalisable variables (those that are free in the type but 
not the typing environment) is problematic for the equational theory of abelian 
groups, as variable occurrence does not imply variable dependency. Later I will 
show another way of looking at this: given the equation a = r, where a is a 
metavariable and r is a type, the solution [r/a] is not necessarily most general! 
In this chapter, I will give an analysis of dependency that exposes and resolves 
the difficulties with generalisation. 

Kennedy (2010, p. 292) gives the example (notation adapted): 

Ax.let y = divxin (ymass, y time), where 
div:Va:W. \//3:U.¥{a * (3) —>■ F(a) —>• F(/3), mass:F(kg), time:F(s). 

Here F(z/) is a type of numbers with units u, defined in Subsection 3.0.2. If 
one adds constraint solving for units to Algorithm W with the usual occurrence- 
based let-generalisation rule, the resulting algorithm fails to infer a type for this 
term, because polymorphism is lost: y is given the monotype F(a) —> ¥{/3 * cU 1 ) 
where a and j3 are unification metavariables, and a cannot unify with kg and s. 
However, if y is given its principal type scheme Vet: U. F (a) —>■ F(/? * a -1 ), then 
the term has type F(/?) —* (¥(j3 * kg -1 ),F(/3 * s -1 )), as described in Section 3.3. 

The difficulty is that the algorithm fails to assign principal type schemes to 
open terms because of the nontrivial equational theory on types. One way around 
this difficulty is to apply a generaliser, “a substitution that ‘reveals’ the polymor¬ 
phism available under a given type environment” 1 , due to Kennedy (1996a) and 
Rittri (1995). Such a substitution preserves types in the context (up to the equa¬ 
tional theory) but rearranges group variables so that the Algorithm W general¬ 
isation rule can be used. Calculating a generaliser is specific to the equational 
theory and technically nontrivial. It is not implemented in F#, so Kennedy’s 
example does not type check: 

> fun x -> let y z = x / z in (y mass, y time) ;; 


error FS0001: Type mismatch. 

Expecting a float<kg> but given a float<s> 

The unit of measure 'kg* does not match the unit of measure ’s’ 

1 Kennedy (1996a, p. 23) 


32 




Term variables x, y 
Type metavariables a, (3 ,7 

= * I u 

= ■ | 0 , ot.k | 0 , a:=p : k | 0 , x:a | 0 , 

= • | E,a:n \ E,a:=p : k 

= • | or.U 

= « I r-M' I F (p) I b I 1 I p*p' I p- 1 

= a I t —>• v | F(z/) 

= o; I b | 1 | v * v' | v~ x 
= kg | m | s | 

= p\Va\K.(j 
= x | A x.t | si | leta; = sini 
= ctx | a: K ] p = p ': f t: a \ a >- cr 7 | J A J' 

Figure 3.1: Syntax 

3.0.2 Extending the framework 

In this chapter I extend the unification algorithm from Chapter 2 (and hence 
type inference) to the theory of abelian groups. Mistaking occurrence for de¬ 
pendency will show up as the source of the difficulty described above, leading to 
a straightforward solution. With more structure in the context than just typ¬ 
ing assumptions, it is easier to see where generality can be lost, and the loss of 
polymorphism can be avoided in the first place instead of recovered after the fact. 

The syntax of contexts, expressions and statements is given in Figure 3.1. As 
before, a context is a list of metavariable declarations or.n, definitions a:=p : n, 
term variable declarations x: a and 9 markers. Now, however, metavariables may 
have kind * (a type) or U (a unit). Similarly, type schemes record the kind of 
quantified variables, and the typing and equality statements include kinds. For 
example, 

a:*,0: W, x: (VqiZT a ^ F(/? * 7 )) 

is a valid context. A common syntax of type expressions p has subgrammars for 
types t and units v. 

Figure 3.2 gives rules to construct a valid context and interpret variables in 
the context. These are similar to the rules for the Hindley-Milner system from the 
previous chapter (Figure 2.3, page 12), with the addition of the kind U. Types are 
extended to include a single new type F (y) representing a numeric type indexed 
by a unit v. A real implementation would allow user-defined unit-indexed types, 
but one suffices for illustration. 


Contexts 0 

Suffixes E 

Unit suffix T 

Type expressions p 

Types r, v 

Units v 

Base units b 

Type schemes a 

Terms t, s 

Statements J 
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fO is a valid context) 


a#© x#0 

0 1 ~ p\K 0bcr:* 0 b ctx 

0, a :=p : k b ctx 0, x : a b ctx 0, b ctx 

(a is a well-formed scheme of kind k in 0 ) 

0br:=t= 0h«:* 0b v.U <d,a:K\- a:* 

0br4t;:* 0bF(i/):* 0 b Va: k. a: * 

0b; v.U 0b v':U 0bi v.U 

0 b b:U 0 b u*i/:U 0 b v- l -.U 0 b V.U 


Figure 3.2: Rules for context validity and well-formed type schemes 


\9 : 0 O C©i 
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9 : 0 O C 0i 

©lb p-.K 

9 : 0o C 0i 0i b p 
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9 p' 

:« 

[]:-C5 

(9, p/a) : 0 o ,o: 

:kQ ©1 

( 9,p/a ) : © 0 , a:—p' : 

K ! 

= 0 
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9 : 0 O C ©1 


9 : 0 O C 0i 





9 : ®o,x:cr E © 1 , x 

:9 a, 5 

9 : 009 E ©19 S 




\9 = 9': Q 0 E 

©i (9 and 9' 

are equivalent metasubstitutions from 

01 

3 to 



9 = 9' : 0 O C ©! 0i b p = p': k 
• = -:-E©i (9,p/a) = (9 , ,p , /a):e 0 ,a:KQe 1 

9 = 9' : 0 O C 0i 0i b p = p':n 0i b p' = 9 p": k 
( 9, p/a) = (9',p'/a):O 0 ,a:=p" : k □ ©i 

9 = 9':Q 0 R©i 9 = 9':G 0 □ ©i 

9 = 9': 0 O , x: a C ©i, x: 9 a, 5 9 = 9': ©o? E ©i 9 8 


Figure 3.3: Rules for metasubstitutions 
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The updated rules for metasubstitutions are given in Figure 3.3. These are 
obvious extensions of the rules given in Subsection 2.1.2 (page 14). 

Recall that a statement J is an assertion that can be judged in a context. The 
syntax of statements from the previous chapter is extended with kind information, 
and the sanity conditions (Lemma 2.1) are updated appropriately: 


Lemma 3.1 (Sanity conditions). 

San ctx 

San (cr: k) 
San (r = v: k) 
San ( t:a ) 
San (cr >- a') 
San (J A J') 


If 0 h J then 0 b San J, where 

ctx 
1-4 ctx 
i-4 t:k A v.k 
i — y c \ * 

a:* A cr':* 
t-4 SanJ A SanJ 7 


Proof. By structural induction on derivations. 


□ 


The key results from the previous chapter, stability (Lemma 2.2, page 16), 
the category structure of contexts (Lemma 2.3, page 16), the Optimist’s lemma 
(Lemma 2.4, page 18) and the isomorphism lemma (Lemma 2.5, page 18) apply 
to the updated notions of statement and metasubstitution without modification. 


3.1 Unification for the theory of abelian groups 

I now consider abelian group unification problems in the framework. The syntax 
of types t is extended with units of measure v given by 

v ::= 

a metavariable 

b base unit 

1 identity 

v * v' product of units 
v~ l inverse 

where b ranges over some set of base units, which would be user-defined in a real 
system for units of measure. Note that units of measure v are just type expressions 
of kind U, but the typing rules ensure they must belong to this grammar. 

The rules for equivalence of types and units are given in Figure 3.4: reflexivity, 
symmetry, transitivity and congruence, plus the four abelian group axioms of 
commutativity, associativity, inverses and identity. 
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eh p = P '-.K 


(p and p' are equal expressions of kind k in 0 ) 


©b p:K 

©b 

© b Po 

p = p':K 0 b pi 

= Pi :k 
= p2'-K 

0 b ctx 

© 9 a:=p : k 

0 h p = p: K 

©T 

p' = p\K 0 b po 

= P2-K 

0 b a = p:K 

0 1 ~ t = r 




© b u 0 = v 2 :14 

0 b r' = 1 

<y :* 

0b v = 14:14 


0bq = u 3 :14 


ehr^r'Eu^!;':* 0 h F(i/) e F (u 1 ) : * 0 h u 0 * iq = v 2 * : U 


0hi/ O Ei/i :U 0h v.U ©h v.U 0h v':U 

0 h l^o" 1 E !/j ~ X \U ©hhi/EJ J-.U. 0h V*v' = v'*V.U 

Q \- vq\IA 0 h ;/i:W 0hi/2:W © h v.U 

0 h (vq * uf) * v 2 = Vq * (iq * v 2 ):U ©hi/* v~ k = 1:14 

Figure 3.4: Declarative rules for unit equivalence 

Let u k mean u multiplied by itself k times and mean (u k ) 1 . Units have 
a normal form fl ^i ki representing the product of some distinct atoms (variables 
or constants) rq, each raised to a nonzero integer power ki. For example, the 
expression a*a*/3*l*/3*a has normal form a 3 * /3 2 . 

Consider the equation a 3 * /3 2 = 1 in the context a : 14,(3 :14. As 2 does 
not divide 3, (3 cannot be defined to solve this equation, but the problem can 
be simplified by taking (3 := 7 * or 1 where 7 is a fresh variable. This leaves 
a * 7 2 = 1 in the context a: U,^:U, which is solved by rearranging and defining 
a 7 -2 . Thus the solution is 7 : 14, a :— 7 -2 : 14, (3 := 7 * or 1 : 14, and indeed 
a 3 * (3 2 = ( 7 -2 ) 3 * (7 * ce -1 ) = 7~ 6 * 7 s = 1 . Along the way, the least common 
multiple of 2 and 3 has been calculated. 

More generally, when solving such an equation, one can ask whether a variable 
has the largest power, and if not, reduce the other powers by it to simplify the 
problem. Some notation is in order. Suppose v = HP , and define: 

maxpow(/y) = max{ h, : v, metavariable}, highest absolute variable power; 

Q k [y) = El uf ki ^ uotk: ) , quotient by k of every power; 

R k(p) = n '•em a-) , remainder by k of every power; 

where quot is truncated integer division and rem is the corresponding remainder. 
The point is that v = (Q k(y)) k * Rfc(^) and maxpow(R^(i/)) < k. 
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(unifying v with 1 in 0 O , T results in 0i ) 


00 II r h p = 1 : U H 01 


0 O II T b v = 1 : U H 0i 

--- U-TRIVIAL --- U-SKIP-SEMI 

0||-I-1 = 1:WH0 0o? ||ri-i/ = l:WH0i5 

a 4. fmv(p) 0 O II T h v = 1 : U H 0i 

e0ja;K || r = x -u^Q^ot.k U - SKIP ‘ TY 

0 O || T b v = 1 : U H 0i 

0 o ,a::(7||ri-i/ = l:WH0i,x:t7 U ' SKIP ‘™ 

©o,T|| • h [/j/al i/ E 1 : WH © x 

- U-SUBS 

0 O , a:=p : k\\Y \~ v = 1 : U -\ Qi,a:= p : k 

k 7^ 0 

-T- U-DEFINE 

0,a:U\\rha k *v =1 : U H 0,T, :W 

| A; | < maxpow(i/) fi fresh 

0 O , T || /3: W h * R fc (i/) = 1 : W H ©i 

- ; -U-REDUCE 

0 O , a: U \\T \~ a k * v = 1 : U H G u a:=p * Q k (v) :U 
I A; I > maxpow(zz) 0 O II a: U b a k * u = 1 : U H ©i 

J -tt- U-COLLECT 

Q 0 ,a:U\\-\-a k *u=l:U-\Q l 


Figure 3.5: Algorithmic rules for abelian group unification 

3.1.1 The abelian group unification algorithm 

In this subsection, I give a new algorithm for unification problems v = z/: U. The 
inverse operation means it suffices to solve problems v = 1 \U. 

Figure 3.5 shows the algorithm presented as a collection of inference rules. 
Given a context © 0 , T and a unit u, the judgment 0 O || T b v = 1 : U H ©i means 
that the algorithm outputs the context ©i such that ©i F v = 1 \U. Note that 
the rules are entirely syntax-directed (up to the equational theory for units): at 
most one rule applies for any possible initial context and unit. They lead directly 
to an implementation, which is given in Appendix B.3 (page 210). 

So how does the algorithm work? If the problem is 1 = 1, then it is solved by 
U-trivial. Otherwise, the algorithm moves back through the context, skipping 
over (meta)variables that do not occur in the problem using u-SKIP-ty or u- 
SKIP-TM, and moving through localities using U-SKIP-SEMI. 
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The suffix T wifi either be empty (written •) or contain only the unknown 
variable with the strictly largest power in is, if any. The U-REDUCE and U- 
COLLECT rules move this variable back in the context, since there is no useful 
simplification that can be applied to it. Other rules will insert the variable into 
the context when it no longer has the largest power. 

The interesting cases arise when a metavariable a, that occurs in the problem, 
in reached. This is written a k *is = 1, always meaning that a (f fmv(//). Suppose 
the normal form of is is fl v i k ' ■ There are four possibilities, either: 

(1) k divides k t for all i; 

(2) is has at least one variable and \k\ < maxpow(/y) but case (1) does not 
apply; 

(3) is has at least one variable and k > maxpow(//); or 

(4) is has no variables. 

Case (1). If k divides ki for all i, then there is some is 0 such that is = is 0 k . 
The rule u- define applies and sets a: = is 0 ~ ] : U to give 

a k * v = a k * u 0 k = (z/ 0 _1 ) fc *v o =1. 


This is clearly a solution, and it is most general for the free abelian group. 

Case (2). If not, and \k\ < maxpow(zy), then the U-REDUCE rule applies 
and simplifies the problem by reducing the powers modulo k. Recall that we 
have v = (Q k (v)) k * R fc (/y) where Qk(C) takes the quotient by k of the powers in 
is. Hence, generating a fresh variable f3 and defining a:=/3 * Q k (isy l gives 

a k *t= (8* *v3*$ k * Q k (is)~ k *is = /3 k * R k (is). 

Case (3). Suppose \k\ > maxpow(//), so neither of the two previous cases 
apply, but there is at least one variable in is. Now k is the largest power of a 
variable, so reducing the powers modulo k would leave them unchanged. Instead, 
the u-COLLECT rule moves a further back in the context. This rule maintains 
the invariant that T contains only the variable with the largest power, if any; the 
invariant also guarantees that T will be empty when the rule applies. 

Case (4)- If is has no variables and k does not divide the powers of the 
constants in is, then a k * is = 1 has no solution in the free abelian group. 
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3.1.2 Correctness of abelian group unification 

The problem-solving apparatus introduced in Subsection 2.1.3 carries over with¬ 
out change to this new setting, where the language of statements is more general. 
In particular, abelian group unification delivers minimal solutions. 

Lemma 3.2 (Soundness and generality of abelian group unification). If the group 
unification algorithm succeeds with © 0 || T b i/ = 1 :W H @i 7 then 0 O , T C 0i is 
a minimal solution of v = 1 \U. 

Proof. By induction on derivations, using the isomorphism lemma (Lemma 2.5). 
For details, see Appendix D.2 (page 239). □ 

Lemma 3.3 (Completeness of abelian group unification). If v is a well-formed 
unit of measure in 0 O? and there is some 8 : 0 O □ ©' such that ©' b 9 u = 1: U, 
then the algorithm produces ©i such that 0 O || • b v = 1 : U H ©i. 

Proof. A suitable metric shows that the algorithm terminates. Completeness is 
by the fact that the rules cover all solvable cases and preserve solutions: if no 
rule applies then the original problem can have had no solutions. This occurs if 
a constant is equated to 1 (e.g. kg * s = 1) or there is one variable and its power 
does not divide the power of one of the constants (e.g. a 2 * kg = 1). For details, 
see Appendix D.2 (page 239). □ 

3.2 Unification for types with units of measure 

Having developed a unification algorithm for abelian groups, I now extend type 
unification to support units of measure, calling group unification from Section 3.1 
as a subroutine to solve constraints on units. As in the type unification algorithm 
of the previous chapter (Figure 2.5, page 21), there are two kinds of rules: 

• ‘Unify’ steps start the process: given an input context 0 O and well-formed 
types t and v, the judgment 0 O br = v : * H ©i means that the unification 
problem r = v: * is solved with output context ©i. 

• ‘Instantiate’ steps handle flex-rigid unification problems: 2 given a context 
©o,S, a type metavariable a in 0 O and a well-formed non-variable type r 
over ©o, S, the judgment 0 O | H b a = r : * H 0] means that the problem 

2 Recall that a flex-rigid, problem is to unify a variable and a non-variable expression; a 
flex-flex problem has two variables and a rigid-rigid problem has two non-variables. 
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a = r : * is solved with output context ©i. The context suffix S collects 
metavariable declarations that r depends on but that cannot be used to 
solve the problem. 

Compared to the previous chapter, the language of types (of kind *) now 
includes a single new type F (u) of numbers parameterised by units. I therefore 
add a type unification rule that invokes abelian group unification: 

©o || • I - i/ 0 * z/i -1 = 1 : U H ©! 

-UNIT 

©o b F(i/ 0 > s F^):* H ©! 

Now suppose the algorithm is used to solve F (f3 0 * f3i) —> a = F(/? 0 ) —>• F(/?i) 
in the context /3 0 : U, a : *, f3\ : U. First the constraint F(/?o * A) = F(/3 0 ) : * 
is reduced to f3 0 * fix = fi 0 : U by unit, and this is solved by group unification 
(Section 3.1) to give fi 0 : U, a : *, fix := 1 : U. Then the constraint a = F(J%| is 
solved to give fi 0 : U,a:= F(l) : *, di : \ :U 

Do the rules in Figure 2.5 extended with the unit rule give a correct unifica¬ 
tion algorithm for the extended type system? The unification algorithm should 
be sound and complete, as the new algorithmic rule corresponds directly to the 
declarative rule, but generality fails. Most general unifiers are needed for com¬ 
pleteness of type inference, so something had better be done. 

3.2.1 Loss of generality and how to retain it 

Suppose the algorithm is used to solve the constraint a = F (/3 0 * /3i) in the 
context a : * , f3 0 : U, : U. As the rules stand, this flex-rigid problem is solved 
by moving /3 0 and fi\ into the previous locality, and defining a resulting in the 
context /?o : W, di : U,a F(/9 0 * A) : *? ■ However, another solution exists, 
namely 7 : U, a F( 7 ) : * , /3 0 : U r {3\ := /V ' * 7 : U, where 7 is a fresh group 
variable. This solution is more general because /3 0 is still local (it has not been 
moved past the 9 marker). Why did the algorithm fail to find this? 

The trouble is that, to solve a flex-rigid constraint, the variable need not 
be syntactically equal to the type: units need be equal only up to the theory 
of abelian groups. The property that equivalent expressions have the same sets 
of free variables 3 holds for the syntactic theory and some other useful theories 
(Remy, 1992) but does not hold for groups. For example, the equation a * a 1 = 1 

3 This property is sometimes called regularity in the literature, but I avoid this term because 
it means too many different things in other contexts. 
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has a free on the left but not the right. Thus variable occurrence does not imply 
dependency. The occurs check in the unification algorithm is overly syntactic. 

To solve this, a flex-rigid constraint can be decomposed into a constraint on 
types, with fresh variables in place of units, and additional constraints to make 
the fresh variables equal to the units. A rigid type decomposes into a ‘hull’, 
or ‘type skeleton’, that must match exactly, and a collection of constraints in 
the richer equational theory. Similar techniques are used for type inference in 
annotated type systems (Nielson et al., 1999, §5.3.2). 

In the example, the constraint a = F (p 0 * pi ) decomposes into two constraints 
a = F(q): * A 7 = 0$ * : U in the context a : * 5 /3 0 : U, Pi : U, 7 : U. Solving 

the first constraint gives 7 : U, a :—¥{j) : * , do: U, /A : U, and solving the second 
yields the most general solution p': U, a :=F(q) : * , /3 0 : U , di(do -1 * 7) : U. 

Committing only to the hull is the minimal commitment entailed by the equa¬ 
tion, as far as the equational theory on types goes. One could even go further 
and solve every flex-rigid equation one constructor layer at a time, so a = r —> v 
would be solved by a = /3 0 —> ^ A /3 0 = r A Pi = v. 

The rules from Figure 2.5 (page 21) can be modified to maintain the invariant 
that the only unit metavariables a flex-rigid problem depends on (i.e. those in the 
rigid type t or suffix 5) are fresh unknowns. Unit metavariables are never made 
less local by collecting them in S as dependencies. Type unification does not 
prejudice locality of unit metavariables: they must be left for group unification. 
The rule 

t non-variable 0 O | • h a = r : * H @1 

-INST 

0 O h a = t : * H 0i 

is replaced by 

t non-variable pi fresh 

©0 f^TZ: * H 0j 

0! h p i = u i :U i H 0 2 

- : - INST 

0 O F a = r{ 17 1 } : * H 0 2 

where r{l7~i 1 } is the hull of the type r, parameterised by a vector of units (so 
F(i'o) —> F(i/i) has hull F(_) —>• F(_) and t{q:o, «i} = F(q; 0 ) —> F(cci)). Vectors 
of equations are solved one at a time, threading the context: 

(~>o H • F A, * U) ' - 1 :WH0, ... 0 n _! || • h pn-i * v n -i~ l = 1 : U H 0 n 

- CONJ 

0 O h p 0 = Vq\U A ... A Pn-x = v n _i :U H 0 n 
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The updated rules are given in Figures 3.6 and 3.7. Apart from the addition 
of the unit rule, and the modification to the INST rule, the only changes are 
minor generalisations, such as changing rules to work with an arbitrary kind k, 
rather than just *. Again, symmetric variants of the INST and define rules have 
been omitted. The implementation is given in Appendix B.4 (page 212). 

Similarly to Definition 2.1 (page 20) in the previous chapter, the instantiation 
part of the algorithm expects a number of conditions to be satisfied: 

Definition 3.1. The quadruple (0 O , S, a, t) satisfies the input conditions if 

• ©o F a: * where a is a metavariable, 

• 0 O ,S hr:* where t is not a metavariable, 

• 5 contains only metavariable declarations /3:k with (3 e fmv(r), and 

• if F(p) is a subterm of r then v — /3 for some /3 with E 3 (3 :U. 

The crucial addition, maintained by the new INST rule, is the last condition. 
This is necessary for generality, as it ensures that every unit metavariable in E 
is a true dependency of r, and completeness, as it ensures that E captures all 
the unit metavariable dependencies of t, so the algorithm will not encounter an 
unexpected unit metavariable dependency and get stuck. 

3.2.2 Correctness of type unification 

With the above refinement, type unification gives most general results. 

Lemma 3.4 (Soundness and generality of type unification). 

(a) If Qo F t = v : * H ©i, then 0 O C ©i is a minimal solution ofr = v:*. 

(b) //©o | E F a = t : * H ©i, then 0 O , E C ©i is a minimal solution ofa = r:*. 

Proof. Proceed by induction on the structure of derivations, as in Lemma 2.6 
(page 22). The majority of the cases are similar to the previous proof, but 
the unit rule is new, the INST rule has been modified. The INST-SKIP-SEMI 
rule requires a more subtle generality proof, in order to verify that instantiation 
moves only genuine dependencies. The input conditions ensure that units always 
occur in the form F(o:), so it is obvious that cc is a dependency. For details, see 
Appendix D.2 (page 240). □ 
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(unifying r with v in 0 O results in Q i) 


@ 0 h t = v : * H 0! 


0 O b To = Vq : * H 01 


0i b Ti = v\ : * H 02 


©o I- (to -0 Ti) = (t»o -0 Ui) : * H 02 

©o || ■ H z^ 0 * z'i -1 = 1 : U H ©i 
0 O b F(i/ 0 ) = F(^) :H0j 1 


- DECOMPOSE 


t non- variable 


Bi'' fresh 


0 O | faM h«Er{f}:Hei 0 X b ft = vp.U H 0 2 


0 O b a = r{ 17 * } : * H 0 2 


« ^ fi 


Q,a:* \~ a = a : 


H0,q:* 0, a: * b a = B : * H 0, a:—B : 

©o b \p/l\ a = \ph\ B ■ * H @i 


© 0 ; l'-—p ■ n\- a = B ■ * B Qi^:=p : k 
0 O h a e ^ * H ©i ft ^ 7 


©o, 7: ac I-Q! = / 5 :*H©i, 7 :/c 


0 O b a = B : * H ©i 
0 O , x:a \- a = B '■ * B @i,x:a 


0 O b a = B : * H ©! 


009 b a = / 


H 0 !? 


- SKIP-SEMI 


©0 II • b A) * I/O" 1 = 1 : W H 01 ... 0 n-l || • b Bn -1 * AAn-l" 1 = 1 ! W H ©„ 
O 0 \~ Bo = Vo'-Lt A ... A Bn-l = Vn-l-U B ® n 


Figure 3.6: Algorithmic rules for type unification (part 1) 
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|Q 0 |SI-Q' = r:*-IQ 1 | (instantiating a with r in 0 O , H results in 0 iy ) 

a fmv(r) 


0 O , a: * | S b a = t : * H 0 O , 5, a:=r : 
©o, 5 h \p//3\ a = [p/0] r:H0! 


- INST-DEFINE 


- INST-SUBS 


Q 0 ,/3-—p : k\E \- a = t : * Qi, Pp : k 

0 O | /3: *, S F ct: = t : * H 0i a ^ (3 /3 e fmv(r) 

0 O , ft : * j:E h a = r : * H 0 X 

0 o |SI-q; = t:*H0i oi ^ /3 /3 ^ fmv(r) 


INST-DEPEND 


0 o ,/3:k | SI-oet: H0i,/3:/{ 


INST-SKIP-TY 


0 o sl-Q!Er:*H0i 

-:- INST-SKIP-TM 

0 O , x:a \ E\- a = t : * Qi,x:a 


0 o |Sh a = r 
00 9 | S b a: = t : * H 0!, 


INST-SKIP-SEMI 


Figure 3.7: Algorithmic rules for type unification (part 2) 
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Lemma 3.5 (Completeness of type unification). 

(a) If the types v and r are well-formed in 0 O and there is some 6 : 0 O C ©' with 
0' I - 9v = 9 t:*, then unification produces 0i such that 0 o l _ t' = r:*H©i. 

(b) Moreover, if 9 : 0 O , S C 0' is such that 0' b 9a = 9r : * and the input 
conditions (Definition 3.1) are satisfied, then there is some context ©i such 
that ©o | H h a = r : * H ©i. 

Proof. Termination of the algorithm can be established via an appropriate or¬ 
dering. Proceed by structural induction on the call graph, observing that each 
rule preserves solutions, and that all (potentially solvable) cases are covered. 
Completeness of appeals to group unification follows from Lemma 3.3. For more 
details, see Appendix D.2 (page 241). □ 


3.3 Type inference for units of measure 

I have given a unification algorithm for types containing units of measure in 
Section 3.2, and this extends to a type inference algorithm for the corresponding 
type system. Given the new types, amended unification algorithm and the ability 
for type schemes to quantify over variables of kind U , no changes to the type 
inference algorithm from Section 2.3 are required. 

Generalisation is easy and there is no need to complicate the type inference 
algorithm to deal with units of measure. The initial context can be extended 
with constant terms that use the new types. Moreover, thanks to the refinement 
of Section 3.2.1, the algorithm copes naturally with the problematic term from 
Subsection 3.0.1, correctly inferring its most general type. Recall the example: 

Ax. let y = divxin (y mass, y time), where 

div :Va:U. \//3:U.¥{a * j3) —>■ F(a) —>■ F(/3), mass:F(kg), time:F(s). 

At the crucial point when the type of y is being inferred, the situation is 

a:*,x:a% /3 0 : U, /A: U h divx:F(/3 0 ) —> F(/?i) subject to a = F(/3 0 * / d 1 ), 

where a is an unknown fresh type variable standing in for the type of x. The 
constraint decomposes into two simpler constraints a = F ( 7 ): * A 7 = /3 0 * /3i : U 
with 7 a fresh unit metavariable. These can be solved one at a time to give the 
solution 7 : U, a := F( 7 ) : *, x : a , /3 0 : U, /A := (7 * /d 0 _1 ) : U. Generalising by 
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‘skimming off’ type variables in the locality gives the type scheme 


7 : U, x : F< 7 > h y : Vft: U. F(/3 0 ) F ( 7 * fa ' 1 ), 

which is principal. Type inference for the whole term succeeds, giving the type 

F< 7 > (F( 7 * kg -1 ), F ( 7 * s -1 )). 


3.4 Discussion 

I have shown how to combine abelian group unification with syntactic unification 
while carefully tracking dependencies in a structured context, so generalisation 
is straightforward. Crucially, contexts capture an appropriate notion of locality, 
so a local solution is more general than a global one. The algorithms presented 
here solve unification problems by making gradual steps towards a solution, and 
it is comparatively easy to check that each step is sound and most general. A key 
point is that flex-rigid equations a = r cannot always be solved by substituting 
t for a, given a nontrivial equational theory. Instead, r decomposes into a ‘hull’ 
(the outer structure that a must match exactly) and a collection of constraints 
in the equational theory. 

This technique can be applied to other equational theories and more advanced 
type systems. The integers are an abelian group under addition, so the work in 
this chapter could be combined with the account of elaboration in Chapter 7 to 
elaborate types indexed by integers. 

In this chapter I have been following the trail that Kennedy blazed, in the 
representation of units of measure using a free abelian group, the observation that 
unification has unique most general unifiers in this case, and the application of 
these properties to type inference. To extend the technique to less convenient type 
systems, I will need to deal with problems that cannot necessarily be solved on the 
first attempt. In the next chapter, I will examine higher-order unification, which 
is useful for elaborating higher-rank and dependent types. ‘Pattern unification’ 
as introduced by Miller (1992) provides a solid starting point, but here an explicit 
representation of postponed unification problems will be essential, because not 
all higher-order unification problems fall into the fragment that can be solved 
immediately. 
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3.4.1 Related work 

Many authors have proposed designs for systems of units of measure. I have 
followed Kennedy’s design, using integer powers, so units form an abelian group. 
Some authors use rational powers (giving a vector space), including Rittri (1995), 
who discusses the merits of both approaches. Chen et al. (2003) give a useful 
overview of work on units, and describe an alternative approach using static 
analysis. 

Several impressive implementations of units of measure use advanced type 
system features such as GHC Haskell extensions (Buckwalter, n.d.) and C++ 
templates (Schabel and Watanabe, 2013). However, the difficulty of expressing a 
nontrivial equational theory at the type level means that they are complex, have 
limited inference capabilities and tend to expose the internal implementation in 
unfriendly error messages. Making units a type system extension, as in F#, 
results in a much more user-friendly system. 

Remy (1992) extends the ML type system with other equational theories for 
which variable occurrence does imply dependency (specifically excluding abelian 
groups). As discussed in the previous chapter, his unification algorithm achieves 
easy generalisation by tracking the ‘ranks’ at which type variables are introduced. 

Sulzmann et al. (1999) propose a version of the HM(X) framework for repre¬ 
senting type systems in constraint form, which avoids the generalisation problems 
discussed in this chapter by allowing constraints to be quantified over instead of 
solving them immediately. This is a very useful technique, although it is practi¬ 
cally desirable to solve unification constraints as soon as possible (in the interests 
of efficiency and good error reporting). 
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Chapter 4 

Miller pattern unification 


Higher-order unification is the problem of finding definitions for metavariables in 
order to solve an equation between two A-calculus terms. It extends first-order 
unification, as discussed in Chapter 2, in that 

• terms have a binding structure, so unifiers must respect variable scope: e.g. 
A x.a Pa Xx.x can only be solved by a := x if the metavariable a may depend 
on the bound variable x ; and 

• terms have a nontrivial equational theory, given by the /3- and 77 -rules : 1 for 
example, Xx.x « Xx.Xy.axy can be solved by a := Xz.z since 

Xx.Xy.(Xz.z) x y =p Xx.Xy.xy = n Xx.x. 

Given these complications it is perhaps unsurprising that full higher-order unifi¬ 
cation is undecidable (Huet, 1973). Most general unifiers do not necessarily exist 
and terms may have infinite sets of unifiers, though they can be generated by a 
semidecision procedure (Huet, 1975). Miller (1992) observed that a useful sub¬ 
problem, unification in the pattern fragment , is decidable and has unique most 
general unifiers if they exist at all. Here metavariables must be applied to spines 
of distinct bound variables, so Xx.x ~ Xx.Xy.a xy is included but A x.a x x fa Xx.x 
is not; observe that the latter has two incompatible solutions a := Xx.Xy.x and 
a := Xy.Xx.x. Equations that look like definitions, are definitions: a X{ 1 fa t can 
be solved by a := A 35 * An application to variables determines a metavariable 
fully, while an application to other terms determines it only in part (for example, 
a (Xx.x) fa t cannot easily be solved). 


L One can consider /3-equality alone, but for the purposes of this chapter I will need both. 









Dependently typed programming languages rely on higher-order unification 
for elaborating source programs, much as Hindley-Milner type inference makes use 
of first-order unification. Languages with a kernel type theory, such as Coq (Coq 
Development Team, 2013) and Epigram (McBride and McKinna, 2004), do not 
need unification in the kernel, but they depend on it to elaborate human-readable 
syntax. Likewise, Agda (Norell, 2007) uses higher-order unification for pattern 
matching and implicit argument synthesis. During the elaboration of a source 
language program, metavariables are inserted to stand for function arguments 
that the user has omitted, and unification problems arise when types do not match 
exactly. Elaboration will be considered in more detail in Chapter 7. Dependent 
types naturally lead to higher-order unification problems, since functions express 
dependency (for example, consider solving for a and /? in Hx: a. ft x fs T ). 

Programmers in a dependently typed language need to grasp the capabilities 
of unification if they are to become productive users of the language. Knowing 
what to omit, because the machine can reconstruct it for you, is a crucial aspect 
of writing comprehensible programs. 

Languages with simple pairs or E-types (pairs in which the type of the second 
component may depend on the value of the first component) motivate extending 
the pattern fragment to projections. For example, consider a hd x ss x where 
postfix hd is first projection. This does not fall in the original pattern fragment 
but has most general solution [(A x.x,/3)/a] where [3 is a fresh variable. 

For many applications, the static pattern fragment is overly restrictive: one 
often has multiple constraints, some of which fall into the fragment and some of 
which do not, but solving one constraint may make bring others into pattern form. 
This leads to ‘dynamic’ pattern unification, where non-pattern constraints may 
be postponed in case they are solvable later. For example, given the constraints 
ax PS /3 and a y y ps t, the latter is not in the pattern fragment, but after solving 
the first constraints via a := \x.j3 the second becomes /3 y ps t. 

Dynamic treatment of constraints is necessary even in first-order problems, 
because there is no fixed positional order of constraint solving that will work in all 
cases. For example, consider the problem (a + [3, a) ~ (3,0) where a and 3 are 
natural number metavariables. If an algorithm always unifies the components 
of pairs from left to right, it gets stuck on the constraint a + 3 ~ 3. On the 
other hand, after solving ««0, the first constraint computes to the much easier 
(3 ps 3. 2 The Coq proof assistant, used as a dependently typed programming 
language, suffers from exactly this problem. 

2 Always unifying from right to left is no better: what if we swap the pair’s components? 
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In this chapter, I present a dynamic pattern unification algorithm for a lan¬ 
guage with full-spectrum dependent types including E-types. It includes: 

• the use of heterogeneous equality constraints to maintain typing discipline; 

• a novel notion of ‘twin variables’ used to simplify problems heterogeneously 
when a variable must be assigned two intensionally distinct types, as in 
(Xx.s:Ux: A. B) fa (\x.t:Tlx: S. T): 

• an extension of the context structure from previous chapters, suitable for 
managing dependency and partial progress on unification problems; and 

• the demonstration of a minimal-commitment unification algorithm that 
makes it easy to deliver most general unifiers, when they exist. 

In Section 4.1, I describe the type theory in which I will work. I give the algo¬ 
rithm in Section 4.2, with a high-level specification via rewrite rules. Correctness 
properties of the algorithm are proved in Section 4.3, although termination is 
problematic. Finally, some concluding remarks form Section 4.4. A Haskell ref¬ 
erence implementation of the algorithm is given in Appendix C (page 214). 

4.0.1 Related work 

Since Huet’s seminal work on higher-order unification for simply typed A-calculus 
(Huet, 1975), many people have sought to extend it to dependently typed calculi, 
in particular the Edinburgh Logical Framework (Harper et al., 1993), also known 
as A n -calculus. Elliott (1990) and Pym (1992) both demonstrated semidecision 
procedures for unification based on Huet’s, using the fact that dependencies are 
erasable in the LF to give notions of ‘type similarity’ (in Pym’s terminology) that 
relate the types of terms being unified. Brown (1996) studied the metatheory of a 
variant of A n -calculus with type similarity, and used this to re-present unification 
as a system of reduction rules. 

In contrast to Huet-style semidecision procedures, which generate a sequence 
of unifiers, Miller’s pattern unification (Miller, 1992) finds most general unifiers 
when they exist, but applies only to a fragment. Duggan (1998) generalised the 
pattern condition to support System F w with simple product types. Reed (2009a) 
described how to apply dynamic pattern unification to LF. He introduced ‘typing 
modulo’ (discussed in Subsection 4.0.3) as a neat simplification of type similarity 
and similar invariants used to handle the complications of type dependency. Abel 
and Pientka (2011) extended Reed’s algorithm to support A ns -calculus (LF with 
E-types) and implemented it for the Beluga language. 
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Separately, higher-order unification algorithms have been developed for lan¬ 
guages based on Martin-Lof Type Theory, such as Agda, or the Calculus of Con¬ 
structions, such as Coq. Here, unlike in LF, full-spectrum dependency means 
that types may be recursively defined and computed from terms by large elim¬ 
ination. Thus term dependencies in types are not erasable to produce simple 
non-dependent types, and the work on unification for LF is not immediately ap¬ 
plicable. Pfenning (1991b) extended pattern unification to the Calculus of Con¬ 
structions, characterising exactly those terms that fall in the pattern fragment 
statically; hence the types can always be unified first. 

This chapter builds on the work of Reed (2009a) and Abel and Pientka (2011) 
to describe unification for a full-spectrum dependent type theory, rather than LF. 

4.0.2 Intensional vs. extensional equality 

Definitional equality in an intensional type theory is the /^^-convertibility re¬ 
lation, written s = t. For a strongly normalising theory, it is easy to test in 
a type-directed fashion, by checking that s and t have the same normal form 
(up to a-equivalence) after computation (^-reduction), expansion of definitions 
(5-expansion) and ^-expansion. It is intensional in the sense that extension- 
ally equal terms need not be dehnitionally equal: for example, s — Ax.tt and 
t — Ax.if x then x else tt are equal on all boolean inputs, but s ^ t. 

Extensional type theories typically add a propositional equality type Id T st 
of proofs that s and t are equal, together with the equality reflection rule 

rh«: Idr s t 
rh s=t:T 

that embeds arbitrary proofs into the definitional equality. Extensional equality 
is undecidable in general: given a description of a Turing machine M, consider 
the function that maps a natural number n to the boolean indicating whether 
M halts within n steps. One cannot hope to decide whether this function is 
extensionally equal to the constantly false function! 

The unification algorithm I will describe finds solutions up to the intensional 
definitional equality, not extensional equality. Finding solutions up to extensional 
equality involves proof search and most general solutions are not (intensionally) 
unique. For example, if a : B —> B is a metavariable and x : B is a variable, 
the problem ax tt has unique solution Ax.tt up to definitional equality, but 
solutions up to extensional equality include Ax.if x then x else tt and other terms. 
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Most type theories have some internal notion of propositional equality in which 
equations can be proved, such as the identity type in Martin-Lof Type Theory 
(Martin-Lof, 1984), which reflects the definitional equality as a type, or coercion 
types in System F c (Sulzmann et al., 2007), where equality evidence is explicit 
but in a different syntactic category to terms. Given a type theory with a suffi¬ 
ciently expressive propositional equality, one could represent unification problems 
as types, and unification could deliver terms (equality proofs) as evidence. How¬ 
ever, in this chapter I prefer to make fewer assumptions about the object type 
theory, emphasising that the work is more widely applicable. 

4.0.3 Heterogeneous equality 

Given the problem Ux: A. B ^ Ux: S. T, a reasonable step to take is to simplify 
it to A » S, B ps T. However, at this stage B and T expect different types for x, 
as the equation between A and S may not be solved immediately. This shows the 
need for a heterogeneous notion of equality, in an intensional setting: it permits 
the expression of equations where the two sides belong to provably (extensionally) 
equal but not definitionally (intensionally) equal types. Such equations would be 
homogeneous in an extensional setting. In general, unification must formulate 
and solve equations between vectors of terms in a telescope, where unifying the 
first 7i — l terms will make the types of the ri th terms equal. The unification 
algorithm will maintain the heterogeneity invariant, that every heterogeneous 
equation involves types whose equality is implied by preceding equations; thus 
solutions will always be homogeneous. 

Reed (2009a) elegantly dealt with heterogeneity using a weaker invariant on 
homogeneous equations, typing modulo , which requires that the two sides be well 
typed up to the equational theory of the constraints yet to be solved. However, 
this means that if there are unsolved constraints left when the algorithm ter¬ 
minates, then some solved metavariables may be ill typed, up to the definitional 
equality. This is problematic for elaboration of a full-spectrum dependently typed 
source language, where typechecking is interleaved with unification, so unification 
must not create ill-typed terms. Norell (2007, Ch. 3) shows how ill-typed solutions 
to metavariables can lead to non-normalising terms and hence non-terminating 
elaboration. The algorithm I present avoids this difficulty by ensuring that all 
outputs are well typed, provided it is given well typed input. 
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Variables 

x, y, z, X, Y, Z 



Metavariables 

a, ft, 7 




Terms 

s, t, S, T 

: = 

n 

1 A x.t 1 c | ns: S. T 1 Ex: S. T 1 (s,t) 

Constructors 

c 

: = 

Set Type I tt ff 

Heads 

h 

: = 

X 

x \ x \ a 

Evaluation contexts 

e 

: = 

• 

| et | e hd | g tl | if(x.T) e 5 1 

Neutral terms 

n 

: = 

h 

e 

Metacontexts 

0 : 

: = 


| e,a:T | ©,«:= t:T \ 0,7 P 

Contexts 

T, A : 

: = 


r ,x:T | T,x:StT 

Substitutions 

5 : 

: = 


S,t/x S, (s, t)/x 

Metasubstitutions 

0, C : 

: = 


6,t/a 

Problems 

P, Q : 

: = 

T 

| T | PA Q | {s:S) ( t: 7’) | Vx:S.P 


Vx:StT.P 


Figure 4.1: Syntax 

4.1 Back to basics 

The type theory for which I will describe pattern unification essentially consists 
of Martin-Lof Type Theory with II and E-types, a type of booleans B and one 
small universe Set. The only form of dependency is a type-level if-expression, 
allowing large elimination. It is based on Kipling, a theory described by McBride 
(2010a) with a model construction in the dependently typed language Agda. 

In this section, I introduce the representations of terms and contexts, give 
the typing rules, discuss the use of ‘twins’ for representing variables with two 
provably equal types, explain the role of substitutions, and recall some standard 
metatheoretic properties. These concepts will be used in Section 4.2, where I 
specify the unification algorithm. 

4.1.1 Term representation 

The syntax of terms is given in Figure 4.1. Types and terms live in a single 
syntactic category, though I will typically write s , t, u or v for terms and S, T, 
U or V for types. A neutral (stuck) term n is represented as h ■ e where h is a 
head and e is an evaluation context, generalising the spine form of Cervesato 
and Pfenning (2003). This allows easy access to the head, which may be a 
variable x, y,z or a metavariable a , ft. The accents on variables will be used 
to deal with heterogeneity, as discussed in Subsection 4.1.4. Evaluation contexts 
include applications, if-expressions and projections from E-types (written postfix 
hd for first projection and tl for second projection). Embedding neutral terms 
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s ■ e JJ t 


(redex s • e reduces to normal form t) 

s ■ e JJ Xx.u [t/x\u\fv s-elf(to,h) s ■ e JJ (to, tf) 

t ■ • JJ t s ■ (e t) JJ v s ■ (e hd) JJ t 0 s * (e tj>) JJ ti 

s • e JJ tt s • e JJ ff s-elfn 

5 • (if(a;. t) e to h) If to s- (if(z.T) e to 4 ) 'JJ 4 s • (e • e') JJ. n ■ tl 

6 t JJ t'\ (applying substitution 6 to normal form t reduces to t!) 

8(h) — s 8 e JJ e 1 s ■ e' JJ t 8t If t' 

8 (h • e) JJ. t <5c JJ c 8(Xy.t)lfXy.t' 

8 S If S' 8 T If T' SSlfS' 8 T If T' Stlft' Sulfu' 

8(Uy:S. T) JJ liy.S'. T' 8(Hy.S. T) JJ ^y.S'. T' 8(t,u) JJ (*', u') 

(applying substitution 8 to evaluation context e reduces to e!) 

8e If e' Stlft' 8e If e' Self e' 

8 (e t) JJ e't' 8 (e hd) JJ e' hd 8 (e tl) JJ e' tl 

Self e' STlfT' 81 If t' 8 u If u' 

8 (if(y.T) e tu) If if fax’) e' t' u' 


S(x) 

I —y t 

where t/x e 8 

8(x) 

1-4 s 

where (s,t)/x e 8 

8(x) 

h4 t 

where (s,t)/x e <5 

8(a) 

h4 Q 


6(x) 

h4 X 


6(a) 

i-4 t 

where t/a e 6 


Figure 4.2: Hereditary substitution 



54 




into normal forms is written n, though the underline will sometimes be omitted. 
Evaluation contexts can be composed in the obvious way, written e • e'. 

In this representation, terms t are always /3-normal but not necessarily 77 -long. 
This is possible thanks to hereditary substitution (Watkins et al., 2003), defined 
in Figure 4.2. Here s • e jj. t means s ■ e reduces to t, while 6 t JJ. t' or 6 e JJ- e' means 
applying the substitution 6 to the term t or evaluation context e results in the 
normal form t' or e' respectively. These reduction relations are all functional, and 
are decidable for well-typed inputs. Moreover, projecting from any term (even 
if it is ill typed), or applying any term to a variable, will terminate; I make use 
of this in the definitional equality rules for functions and pairs. In the rules, 
I sometimes write redexes in terms, where formally there should be additional 
premises referring to the reduction relations. 

A telescope A = (x*: 7* ) is a vector of name bindings with corresponding 

types, where each type T { may depend on the variables a<),_, aWi- The single 

binding notation Ux : S. T or A x.t generalises in the obvious way to bind a 
telescope nA. T or XA.t. Similarly h A is the application of the head h to the 
variables bound in A. The non-dependent n and E, where x does not occur in 
the codomain T, are written S —>• T and S x T respectively. 

4.1.2 Contexts and unification problems 

In the style of contextual type theory (Nanevski et al., 2008), I separate the 
metacontext 0 , which contains metavariables and unification problems, from the 
context T, which binds variables. In terms of mixed quantifier prefixes, this 
amounts to maintaining an 3V-prefix, a normalised representation of contexts 
in which the existential quantifiers (metavariables) appear before the universal 
quantifiers (variables). This avoids the need for Miller’s explicit ‘raising’ step. 

Unlike contextual type theory, however, I do not represent metavariable con¬ 
texts explicitly: metavariables simply have n-types. This identification of the 
object language function space with parametrisation in the metalanguage is con¬ 
venient, when the object type theory is sufficiently expressive, but is not essential. 
In Chapter 7, where the type language lacks first-class higher-order functions, I 
will make use of parametrised metavariables instead. 

A context T is a telescope that may also include a novel form of binding, to deal 
with heterogeneous hypotheses for unification problems (see Subsection 4.1.4). 
The set of variables bound by a context is written vars(T). 

A metacontext 0 is a list of metavariables a, each carrying a type and possibly 
a definition, and unification problems P. Scope is managed according to the 
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invariant that each entry depends only on those that precede it, and in terms, 
metavariables are explicitly applied to all the variables they may depend upon. 

Unification problems include heterogeneous equations (s: S) ~ (t: T), uni¬ 
versally quantified variables, truth, falsehood and conjunctions. For brevity, I 
will sometimes omit the types in equations, writing s m t. In Subsection 4.0.3 I 
remarked on the need for the terms being unified to have different types. 

For example, 

a : B —» B, /3: B, ? Mx : B —» B. (a (x j3) : B) « (x 13 : B) 

is a valid metacontext, which declares metavariables a and d and has a single 
unification problem with parameter x. 

A substitution <5 or metasubstitution 9 contains terms with which to re¬ 
place variables or metavariables from a context or metacontext. The identity 
(meta) substitution is written t, and a substitution written as a finite map (such 
as [s/x]) implicitly acts as the identity on all other variables. I will sometimes 
write t{s} instead of [s/x] t where the choice of free variable x is obvious, or to rep¬ 
resent a term that includes s as a subterm. Typing rules for (meta) substitutions 
are given in Subsection 4.1.5. 

4.1.3 Typing rules 

The typing rules are given in the following figures. They define judgments for 
well-formed metacontexts, contexts and problems; for definitionally equal /35- 
normal terms; and for true propositions of the unification logic. In the usual 
bidirectional style (Pierce and Turner, 2000), the definitional equality judgment 
is split in two: there is one judgment for normal terms, where a type is given as 
input, and one for neutral terms, where a type is produced as output. In the in¬ 
terest of brevity, definitional equality is treated as a partial equivalence relation, 
with the typing judgment being the diagonal of equality. Crucially, the defini¬ 
tional equality, and hence typechecking, is decidable 3 using standard techniques 
(Coquand, 1996; Chapman et al., 2005; Loh et al., 2010). Appendix C.3 (page 
221) gives a Haskell implementation of the typechecking algorithm. 

In particular, the theory is well-founded because there is only one universe 
Set: Type, and Type itself is not a well-typed term. (Formally, T : Type should 
be considered a separate judgment to t: T.) 

3 Strictly speaking, it is not possible to decide well-formedness because it depends on the 
truth of propositions in the unification logic, which is not decidable. In practice, this does not 
matter, because I can always assume that the algorithms are given well-formed inputs. 
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The judgments 0 b mctx, 0 | T b ctx and 0 | T b P wf, defined in Fig¬ 
ure 4.3, mean respectively that 0, T and P are well-formed. Contexts and 
metacontexts must bind distinct variables, as xfiP means x is fresh for T and 
a #0 means a is fresh for 0. Note that well-formed problems are required 
to satisfy the heterogeneity invariant: for (s : S) ~ (t : T) to be well-formed, 
(S: Type) « (T :Type) must be true in the unification logic. 

The judgment 0 |rbT 9 s^ 7 t^f, defined in Figure 4.4, means that 
s and t are definitionally equal terms checked at type T, with 77 -long standard 
form u (regarded as an output). This ternary presentation of equality is novel, to 
my knowledge. It is often useful to pick a canonical representative when working 
up to an equivalence; for example, it makes the admissibility of symmetry easy 
to prove. As in the work on Kipling by McBride (2010a), this judgment really 
expresses the fact that s and t are equivalent syntactic presentations of u. 

The definitional equality includes type-directed rules that compare functions 
by applying them to a fresh variable, and compare pairs by computing their 
projections, thereby covering both the 77 -laws and congruence for functions and 
pairs. A type is atomic if it is not a II- or E-type: this is used in the change of 
direction rule to ensure that the equality judgment is syntax-directed, as otherwise 
it would overlap with the rules for functions and pairs. 

The judgment 0 | T b h ■ e ^ h" ■ e" ^ bl ■ e' E T, defined in Figure 4.5, 
means that the neutral terms h ■ e and h' ■ e' are definitionally equal with inferred 
type T and standard form h" ■ e". Note that there is no rule for inferring the 
type of a defined metavariable a t: T; rather, definitions must be immediately 
substituted out, which simplifies the presentation of the algorithm. 

The judgment 0 | T b P, defined in Figures 4.6 and 4.7, means that P is true, 
i.e. it follows from hypotheses in the metacontext. This defines a unification logic 
in the sense of Pfenning (1991a), where the separation of the metacontext from 
the context amounts to keeping all existential quantifiers outermost. In terms of 
the analysis by Martin-Lof (1996), this judgment says that P ‘is true’, whereas 
the judgment 0 | F b P wf says that P ‘is a proposition’. 

I will sometimes omit the standard form, writing 0|rb T 3 s = t instead 
of 0 | T b T 3 s ^ u ^ t. The typing judgment 0 | T b T 3 t is defined as 
0|Tb T 3 t = t, meaning the equivalence relation is reflexive on well-typed 
terms by definition. Similarly, I will sometimes write 0 | T b h ■ e e T instead of 
0|Tb h-e^h' -e’^h-ee T. 
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(0 is a valid metacontext) 


0 b mctx 


a#e 

© I • b P wf 0 I • b Type 9 T a#0 0 | • b T 3 t 

■ b mctx 0,?Fb mctx 0,a:Tb mctx 0,«:=bTb mctx 


0 | T b ctxT| 

x#r 

0 b mctx © | T b Type 9 T 
0 | • b ctx 0 | T, x : T b ctx 


(V is a valid context in metacontext 0 ) 

x #r 

© I r b (5 1 : Type) ~ (T: Type) 

0|r,x:5|Tbctx 


©|r b p w f| 


(P is a well-formed problem in 0 and V) 


0 1 r b ctx © | r b ctx 

© | r b t wf © | r b jl wf 

© | r b ctx 

0 | r b (Set: Type) ~ (Set: Type) wf 


© | r b p wf 
©,?vr.p|rb q wf 
© | r b p a q wf 

©|rb sbs ©|rb T3t 

© I T b (5: Type) (T: Type) 
0|Tb (s:S) w (t:T) wf 


0|r>:SbPwf O \ T, x: S$T P wf 

e\r\-\/x:S.Pwi 0|rbVx:Sir.Pwf 


Figure 4.3: Well-formed contexts 
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0|T h | (type T accepts s equal to t with standard form u) 

0 | r h ctx 0 I r b Set 9 S 4 U ]= T 

0 | r h Type 9 Set =[ Set ]= Set 0 | V h Type 9 S =[ U ]= T 

0 I r h Set 9 So =( U ]= S! 0 I r, x: U h Set 9 To =[ F }ee T x 
0 | r h Set 9 Ux:S 0 . T 0 ee[ Ux:U. V ]= ILc: Si. 

sxJJ-s' txlft' 0 | T, x: U \~ V 3 s' ^ t' 

e\T\-Ux:U. V 3 s^Xx.u^t 

0 I r h Set 9 So =[ U ]= 51 0 I r, x: U h Set 9 T 0 =[ V }ee Jl. 

0 I r h Set 9 Ex: S 0 . T 0 ^ Ex: U. V ]= Ex: Si. 7\ 

5 HD Sg 5 TL JJ, Si 

t HD Jj- to t TL JJ. tl 

e\T\- U3s 0 ^u 0 ^t 0 

01 r h v{u o} 9 si ^ ui ]= k 01 r h ctx 

Q\T\-Ex:U. V 3 s^(u 0 , Ul )}=t 0 | T b Set 

0 1 r i- ctx 0 1 r h ctx 

0|rhB9tt=[tt]=tt 0 |T bB 9 ff ff 

S atomic 

0 | T h h-e^h" -e'^h' -e' e T 0 | T b Type 9 S ^ U ]= T 
0 | T b S 3 h • e ee { h" • e" ]= h' • e' 


Figure 4.4: Definitional equality: normal terms 
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| Q | T b h ■ e ^ h" ■ e" ^ h' ■ e' g T | (h ■ e equals h' ■ e' with inferred type T ) 

<d 3 a: T 0 | T b ctx T 3 x: T 0 | T b ctx 

0|ri-a-#^a-«^«-*e T 0|ri-a:-»^a:-»^2:-*e T 

r 3x-.s\t 0|rbctx r 3 x:S%t ©|rbctx 

0|ri-i;-»^a:-»^a:-»eT 

0 | T b h ■ e ee{ h" ■ e" }= h' ■ e' e Tlx : U. V 0 | T b U 3 u =[ u" ]= u' 

0 | T b h ■ e u ^ h" ■ e" u" ^ h' ■ e' v! e V{u"} 

© | T b h - *i^ h" ■ e" ]= h' ■ £-[& %x: U. Ib 
0 | T b h • e HD =[ h ■ e!' hd ]= h ■ e' hd e U 

© I r b h -,#e[ h" ■ e" ^ ti ■ e l .E Ex: U. V 
0 | T b h • e n,l^ h" • e H jl h' • e' tl £ V{h" ■ e" hd} 

0|rb/i-e^/i"-e"^/j'-e'eB 0 | T, x:B b Type 3 S^U^T 

© | r b u{ tt> 9 u ^ u" ]= u' © | r b u{ ff} 

0 | r b h ■ if(z.s) e if^.c/) e u" ^ h! ■ if( x .T) e' u' i/ e C/{/i w • e"} 


Figure 4.5: Definitional equality: neutral terms 
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© | r b p 


(P is true in the unification logic) 


©irbctx e|rbx 0|rbPwf 0|r,x:PbP 
0|rbT 0|rb p 0|rbVx:5.p 

0|Tb (P:Type) w (T:Type) 0 | T b Type 9 S ee{ U ]= T 

Q\r,x:StThP e\F,x:U\- P{x,x} 

0\T\-Vx:StT.P 0|rbVx:5tr.P 


0 V b \/x:SiT. P 

0|Tb Vx:S.P 0 | r b Type 3 5^ T 

0|rb59 s e\r\-U3u 

0 1 r b p{s} 0|rbP{«,«} 


0 9?P 
0 1 r b ctx 

0 |rbP 


0|rbP 0|rbg 0|rbPAQ 0|rbPAQ 
©|rb pa q 0 |rbP ©|rb q 


e\r^Ux:A.B^Ux:S. T 
0|Tb A « S AVx:AtS.B{x} « T{x} 


0\r\-Zx:A.B^Zx:S. T 
0|r b A « S A\/x:AtS.B{x} « T{x} 


0 | T b Type 3 S^U^T 
0|Tb U 3 s = t 


0|r b (s:S) « (P T) 


0 1 r b ctx 

0 | r b (Set: Type) « (Set: Type) 


0|Tb (PT) « (s:5) 
0|Tb (s:S) « (t:T) 


0 1 r b (i 0 
0 1 r b (ti 

T„) «= (ij 
r,) »(fa 

3) 

r 2 ) r^Ptr 0|rbctx 

0 ,rb(i () 

To)«(fc: 

T 2 ) 0|Tb (f:5)w(i:T) 


Figure 4.6: Unification logic 
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0|rbP 


0|Tb (5: Set) « (U: Set) 0 | T, x: St U b (T{x} : Set) ft* (U{x}:Set) 
0|T b (ILc:S. T : Set) « (ILc: U. 7: Set) 

0|Tb (5: Set) « (U: Set) (-) F, £: Si U b ( T{x) : Set) *> (U{x}:Set) 
0 |T b (Ex:5. T : Set) « (Ex: U. U:Set) 

0|r,x:5JC/b (sx:T{x}) ft* (tx: U{x}) 

0|Tb ( s:Ux:S. T ) » (t: Ux: U. V) 

0 | T b ( 5 hd:S) « ( t hd: U) 0 | T b (stl: T{shd}) « (^tl: U{t HD }) 
0|T b (s:Ex:S. T) « (t:Ex: [/. U) 

0|Tb (n:nx:5. T) « (n^ILc: U. V) 0|T b (s:S) ft* (t: t/) 

0 | T b (ns: T{.s}) « (n’t: V{t}) 

0|rb (n:Ex:S. T) «* (rb:Ex: U. V) 

0|Tb (n HD :S) re in' hd : U) 

Q\T\-{n:Ex:S. T) « (r/:Ex: U. V) 

0|Tb fTOTL:r{n HD }) « (n ; TL: 

0 | T, x:B b (T: Type) * (7*: Type) 0|Tb (n:B) » (n^:B) 

0 | r b (to: r{tt}) « %: rjtt}) 0 | r b (4 : T{S}) « (t [: Hg}) 

0 | T b ( if ( g .r)W Mu r{5» w ( if^rpn 7 t' Q t [ : T ,, {s , » 


Figure 4.7: Unification logic: congruence rules 
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4.1.4 Twins 

Unification will require the incremental simplification of unification problems. In 
a heterogeneous setting, an immediate question is how to simplify the problem 

(. s:Ux:S. T) w (t: Ux: U. V), 

since it would not be type-correct (absent typing modulo) to produce 
Vx:S.(sx:T) « (tx: V). 

We need x : S on the left and x: U on the right, and we need to know that they 
are the same x. This motivates the introduction of twin variables, allowing the 
problem to be simplified to 

\/x:S$U. (sx: T{x }) ^ (tx: U{x}) 

where x and x represent the same variable at two different types, bound by 
x:S\U. The heterogeneity invariant (Subsection 4.0.3) means that S and U will 
be constrained to be equal by problems in the metacontext, but have not yet 
necessarily been unified. If the types become dehnitionally equal, the twins can 
be replaced with a single variable. On the other hand, the fact that they are 
different might not prevent the problem from being solved (if at least one of s 
and t is a constant function, for example). 

Twins bind a single name, but occurrences of the variable mark which twin 
they refer to. Thus they can be distinguished when typechecking, and substitution 
must replace them with a pair of terms that are provably equal. Of course, twins 
are bound as parameters of unification problems, not in terms, so /3-reduction 
never substitutes for twins. I write x ~ y if x and y are identical or twins. 

If unification problems were represented as types, twins could be distinct 
variables with a proof of their (propositional) equality; replacing them with a 
single variable would exploit the elimination principle for propositional equality. 

Definitional equality is tested in the algorithm when typechecking a candidate 
solution for a metavariable, but it treats twins as distinct, so the presence of 
twins may prevent a metavariable being instantiated with a purported solution, 
as indeed it should. When calculating the free variables of a term, the twin 
annotations are ignored, so fv(£) = fv(x) = fv(x) = {x}. 
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(S is a substitution from A to Y) 


0 | T b 5: A 


0 | T b 5: A 0 | T b 5: A 

0|rhctx 0|rb<5T3t 0|rb (s-.ss) » (t-.ST) 

0|T b © I r b (<5, t/x):A,x:T 0 | T b (5, (s, t)/x):A,x:StT 


9 :0 □ 0' (9 is a metasubstitution from 0 to O') 

O' b mctx 6b 0 □ 0' 0 7 1 • b 9 T 3 t = 9 s 

C0' (9,t/a):0,a:= s: T j= 0' 

0:0 C0' 0'|-b0T9* 0:0 □©' 0' | • b 0 P 

(fl,t/a):e,a:rce' 0:0, IP C 0' 


Figure 4.8: Typing rules for substitutions and metasubstitutions 

4.1.5 Substitutions and metasubstitutions 

Figure 4.8 defines well-typed substitutions 6 and metasubstitutions 9. They are 
applied to terms as defined in Figure 4.2, and extended homomorphically to 
syntax containing terms in the usual way. 

The judgment 0 | T b §: A means that 6 substitutes a well-typed term in T 
for every variable in A. Note that two provably equal terms may be substituted 
for twins, since twins are not required to be definitionally equal. 

The judgment 9 : 0 C 0' means that 9 substitutes a well-typed term in 0' 
for every metavariable in 0. Moreover, any problem hypothesised in the original 
metacontext must be true somehow in the new metacontext. This allows meta¬ 
substitutions to be lifted to apply on derivations, as shown by Lemma 4.2 below. 
Thus they give rise to an appropriate notion of stability, as in Subsection 2.1.2 
(page 14). Two metasubstitutions are equivalent if they assign definitionally equal 
terms to each metavariable, as defined in Figure 4.9. 

The identity substitution ton A includes x/x for each x: T and (£, x) / x for 
each x\S\T in A. Weakening is silent, so 0 | T b t: A holds whenever T binds all 
the variables bound in A. 

I will also use i : 0 C 0' for metacontexts, to represent an identity or inclusion 
metasubstitution. If 0' contains definitions for some of the metavariables in 0 
then these definitions will be expanded by t, to maintain the invariant that well- 
typed terms are always /35-normal. 


64 



9 = 9 ': Q □ ©' (6 and 9' are equivalent metasubstitutions from 0 to O') 

9 = 9' :©□©' 

©' b mctx ©' | • b 9T 3 t=t' ©' | ■ b 9T 3 t' = 9s 

• = C ©' (9,t/a) = (9',t'/a):0,a := s: T \Z O' 

9 = 9':0^0' 9 = 9':OQO' 

©' | ■ b 9T 3 t = t! ©' | • b 9 P 

{9,t/a) = {9',t'/a):0,or.T C ©' 0 = O':&,? P Q & 


Figure 4.9: Equivalence of metasubstitutions 

4.1.6 Properties 

All the usual metatheoretic properties hold. Where proofs have been omitted, 
they are by structural induction on derivations. 

Lemma 4.1 (Substitution). Suppose © | F b S: A. Then 

(a) If © | T, A, P b ctx then © | T, 8 V b ctx. 

(b) //©|r,A,P b Pwf then 0\T,ST' SP wf. 

(c) //©|r,A,r' b T 9 s^ u}ee t then G\r, Sr b ST 3 5s^v^5t. 

(d) If 0 | T, A, T' b ho ■ e 0 ^ h 2 ■ e 2 ^ hi ■ e\ e T then 

© | T, 5 V b 5 fe § {ho • e 0 ) =[ u ^ 8 (h • ei). 

(e) If © | F, A, P b P then © | F, 5 P b S P. 

(f) //©|r,A,Pb<wr" thenG\r,8r\-8-8':5r". 

Lemma 4.2 (Metasubstitution). Suppose 9:0 □ ©'. 
fa) If 0 | T b ctx then O' \ 9T b ctx. 

(b) If © | T b P wf then 0'\9T^9P wf. 

(c) If © | T b T 3 s ee[ u ]= t then O' \9F b 9 T 3 9 s =[ u ]= 91. 

(d) IfO | T b h ■ e =[ h" ■ e" ]= h' ■ e' e T then O' | 0r b 9 T 9 9 (h • e) = 9 (h' ■ e'). 

(e) If © | T b P then 0'\9T^9P. 

(f) IfQ\T\-8:A lhenO'\9V\-98:9A. 
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Lemma 4.3 (Sanity conditions). 

(a) If 0 | T b ctx then © b mctx. 

(b) If 0 | T b P wf then 0 | T b ctx. 

(c) IfQ\T\-T3s^u^t then © | T b ctx. 

(d) If 0 | T b h ■ e ^ h" ■ e" ^ h! ■ e' e T then 0 | T b Type 9 T. 

(e) If 0 I r b P then 0 | T b P wf . 

Lemma 4.4 (Definitional equality is an equivalence relation). 

(a) // 0 | T b T 3 t then © | T b T 3 t = t. 

(b) If 0 | T b T 3 s =[ v ]= t then 0|rbT9^^s. 

(c) If Q | T b T 3 t ^ u ^ t 1 and © | V b T 3 t' ^ v ^ t" then u = v and 

e\T\~ T 3 t^v^ t". 

Proof. Reflexivity, part (a), is precisely the definition of the typing judgment. 

Symmetry, part (b), is by structural induction on the derivation. Since the 
standard form is preserved, it is easy to establish symmetry, because the rules use 
the standard form rather than choosing one side arbitrarily (and asymmetrically). 

Transitivity, part (c), is by structural induction on the first derivation and 
inversion on the second. The rules are syntax-directed, so in each case, the last 
rule of the second derivation must be the same as the last rule of the first. □ 

Lemma 4.5 (Context conversion). Suppose 0 | T b Type 3 S = T. Then 

(a) © | T, x: 5*, A b ctx implies © | T, x : T, F' b ctx; 

(b) 0|r,i:S,rbP wf implies 0 | T, x: T, F b P wf; 

(c) © I r, x: S, r' b U 3 s ^u^ t implies 0 | T, x : T, R b U 3 s ^ u ]= t; 

(d) © | T, x: S, D b h ■ e ^ h" ■ e” ^ h' ■ e' e U implies there is some V such that 

0 | T, x : T, R b h ■ e ^ h" ■ e" ^ h' ■ e' e V and 

0 | r, x: T, R b Type 3 U= V; 

(e) © | T, x : S, D b P implies 0 | T, x: T, D b P. 

(f) Q\T,x:S,r \- 8:A implies ©|r,x: T,V b 5: A. 

A similar result applies to twins. 

Lemma 4.6 (Conversion). If 0 | T b Type 3 S = T and 0|rb59s^?i^f 
then 0|Tb T 9 s ^ w ]e f. 
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4.2 Specification of unification 


Having shown how to represent unification problems in context, let me address the 
question of how to solve them. Following the approach of the previous chapters, 
the idea is always to make small, local changes to the metacontext, each of which 
is type-correct, makes the problem simpler and makes no unforced intensional 
choices. This ensures that any solution found is most general. 

In the following subsections, I will examine the range of problems one might 
encounter, and discuss the step to take in each case. Then I will summarise all 
the steps of the algorithm. The steps are divided into five main groups: 

• solving equations of the form axl 1 t by a \= Xxl 1 .t (Subsection 4.2.1); 

• solving equations a x i ' 1 & a Yi l by limiting the domain of a (Subsection 4.2.2); 

• gaining information via pruning (Subsection 4.2.3); 

• simplifying metavariables by removing E-types (Subsection 4.2.4); and 

• simplifying problems locally (Subsection 4.2.5). 

The rules are not deterministic, as they permit working on problems in any 
order, but the nondeterminism does not matter: every step is most general, so the 
order will not affect the final result. A deterministic algorithm can be obtained 
from the rules by choosing a suitable order (such as leftmost problem first). 

Since definitions must be immediately substituted out, in order to keep ev¬ 
erything 5-normal, I write 0, a :=* t: T, S to represent 0, cc := t:T, [t/a]E. 

4.2.1 Solving problems by inversion 

Given the metacontext 


<d,a:T —>• T, ?VT: T. ax « x, 

where the equation looks like a definition, it should be unsurprising that 
0, a := Xx.x: T —>• T, ? \/x : T. x m x 

is a most general solution. Miller (1992) observed that, in general, the problem 
VT. a Si 1 ~ t has unique solution a := Xx^.t provided that the evaluation context 
of a is a list of distinct variables containing all the free variables of f, and a does 
not occur in t. 
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On the other hand, an equation like att ss t is not a good definition for a: 
taking a := A x.t is a solution but is not most general, because another equation 
might require a ff ~ s for some s ^ t. Defining a by case analysis is not most 
general as it makes an unforced intensional choice: a later equation might demand 
a ~ Ax.fF. Intuitively, Miller’s pattern condition says that only an application 
to variables ‘captures the whole nature’ of the metavariable; an application to 
non-variables only determines it for those specific arguments. 

Linearity 

It is crucial that variables occurring in t appear linearly (exactly once) in xf. 
The equation /3 xx x cannot be solved immediately, as d could project either 
its first or second argument, so there is no unique most general solution. On the 
other hand, 7 yxy ~ x can be solved unambiguously by 7 := Xy 0 x y\.x despite 
the repetition of y. The ay 1 may include twins, which are treated as equal for the 
purposes of this check. 

Occurs check 

If a occurs in t, then it is obviously unsound to use t as the definition for a. 
However, the question of whether the problem can have a solution at all is more 
subtle, and depends on the exact form of the occurrence. 

A subterm occurs flexibly if it is in the evaluation context of a metavariable, 
and rigidly if not. In the term ax —>• y z, a, y and z occur rigidly while x 
occurs flexibly. Miller (1992, p. 26) describes rigid occurrences as ‘permanent’ and 
flexible occurrences as ‘possible’, because flexible occurrences might be removed 
by substituting for metavariables but rigid occurrences cannot. A rigid occurrence 
is strong if it is not in the evaluation context of a variable, so no substitution for 
variables can remove it. In the example, y occurs strong rigidly but z does not. 

I write fmv(t) for the set of free metavariables and f v(t) for the set of free 
variables of t. Either may have a - rig or - srig superscript to include only those that 
occur rigidly or strong rigidly (respectively). 

Reed (2009b, §5.1.5) observes that when performing the occurs check before 
solving a metavariable, a problem is definitely unsolvable if 

• the metavariable occurs strong rigidly in its own candidate solution, such 
as in a x «■ a tt —>• a ff; or 

• an application of the metavariable to variables occurs rigidly in its own 
candidate solution, such as in ax^i x {ax). 
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If a weak rigid occurrence of a metavariable is applied to non-variables, the prob¬ 
lem may have solutions, for example y fa y {J3 (\x.x)) is solvable (by taking 
ft := Ay.ytt, amongst other things). Again, Miller’s pattern condition appears: 
only an application to variables determines the whole nature of a metavariable. 

Permuting the metacontext 

If t depends on some metavariables declared after a, these must be moved prior to 
a for the definition to be well-scoped. However, other metavariables may depend 
on a, so they must remain after it. For example, given the context 

0, a : Set, /3 : Set, 7 :a,7 a m j3 ^ j3 

an appropriate solution is 

0, /3 : Set, a j3 —>• (3 : Set, 7 :/?—>/?. 


In general, solving 

0, a : T, 3, ? VT. axi* & t 

requires finding a dependency-respecting permutation of 3 into two segments 3 0 
and Si (written 3 = Sq, 3i), where 3 0 contains all the metavariables that occur in 
t and its type, and does not depend on a. If the necessary permutation does not 
exist, then a cannot be solved immediately, though solving other metavariables 
may remove the dependency cycle. The existence of such a permutation can be 
determined in a small-step fashion by scanning dependencies from right to left, 
as in the instantiation judgment for first-order unification (Figure 2.5, page 21). 

Typechecking 

Once the algorithm has a candidate solution A for a, it must check that 
the solution is well typed, as heterogeneity means that this is not guaranteed. In 
particular, the type of t might not be definitionally equal to the type of ax{\ or if 
some twin variable y occurs in ly 1 and y occurs in t, then the solution will not be 
valid until the types of y and y become definitionally equal. Strictly speaking it 
is not necessary to fully recheck the solution: it is enough to test these conditions 
directly and rely on the fact that the original problem was well-typed. A real 
implementation would record the desired solution for a and the constraints that 
must be solved before it can be applied, as in Agda (Norell, 2007, Ch. 3). 
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intersect • • • !->• 


intersect (A ,z:S) (xi\ x ) (?/**, y) 


intersect A Xi‘y i l ,z\S if x ~ y 
intersect A x^Yi 1 otherwise 


Figure 4.10: Intersection 

4.2.2 Solving flex-flex problems by intersection 

As well as equations between an eliminated metavariable and an arbitrary term, 
some equations have the form a ■ e ~ a ■ e', with the same metavariable on 
both sides but different evaluation contexts. If both contexts are applications of 
lists of variables, then a most general solution is given by restricting a to those 
arguments on which the two lists of variables agree. For example, a solution of 

0, a: T —>■ T —>■ T,l\/x:T.\/y:T.axx^ayx 

is possible only if a does not depend on its first argument, giving 

©,/3:T-> T,a:= \_.p-.T ^ T —>• T,?Vx:T. {j5x\T) ps (/3x:T) 

where f3 is a fresh metavariable. 

Figure 4.10 defines the operation intersect A xi l yl l , which takes a telescope A 
and two lists of variables to fit it, and produces the telescope on which they agree. 
Twin variables are considered equal for the purposes of intersection, though in 
any case, twins could be replaced with a single variable since they must share a 
common type. Given the context 

0, cc:IIA. T, S, ?Vr. axi 1 ~ aYi 1 

the problem is solved by creating a fresh metavariable and defining 

0, j3 : IIA'. T, a :=* XA./3 A': I1A. T, S where A' = intersect A y* * 

provided the free variables of the codomain T are retained in the telescope A'. 

In LF, one can define intersection for arbitrary argument lists that contain 
no metavariables, but this is not possible in a type theory with large elimination. 
For example, aitx ~ a tty does not imply that a is independent of its second 
argument, as it might be defined by case analysis on its first argument. 
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4.2.3 Pruning 

The problem in 

Q,a:(T^ T) -> T,?Vx:(T^ T).Wy:T.ax^xy 

is unsolvable, because there is no way for a to depend on y, since it does not 
occur as an argument on the left-hand side. On the other hand, 

G,P:T -)• T,a:(T T) -)• T,?Vx:(T ->■ T).Vy: T. ax & x (p y) 

can be solved by observing that ft may not depend on its argument, so it must 
be of the form A _ .7 for some fresh metavariable 7 . This gives 

0 , 7 : T, : fi := A_. 7 : T —> T, ct: ( T —>• T) — >• T,?Wx:{T -)■ T).\/y: T.ax & x^ 
which can be solved by 

0, 7 : T, /? := A_ . 7 : T —> T,a := Ax.x 7 :(T^ T) -> T. 

For a problem of the form VT. a • e ~ t to be solvable, all the free variables of t 
must occur in e; otherwise, they will be out of scope for solutions of a. If any out- 
of-scope variables occur rigidly in t, then the equation can never be solved. If an 
out-of-scope variable occurs flexibly, in the evaluation context of a metavariable, 
then it might be possible to remove the occurrence by pruning the metavariable, 
restricting its telescope of arguments. 

Pruning cannot always remove occurrences of out-of-scope variables. For ex¬ 
ample, pruning the equation \/x: T. a « ft (7 x) fails because it is not clear which 
metavariable ignores its argument: either ft or 7 could be constant, so there is 
no most general solution. In this situation, the unification algorithm will have to 
tackle other constraints, which may result in the problem becoming easier. 

Moreover, knowing {3itx cannot depend on x does not mean that (3 cannot 
depend on its second argument, because it might be defined by case analysis on 
the first argument (so removing other arguments might lose solutions). Pruning 
therefore retains arguments only if they are variables, failing otherwise. Once 
again, Miller’s pattern condition appears: a constraint captures the entire be¬ 
haviour of a metavariable only if the metavariable is applied to a list of variables. 
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(pruning t to V requires j3 to have telescope A) 


pruneTm Vt !->• (/3, A) 

©9/5:IIA. T pruneVAt/ (->• A' 
fv(T) c vars(A') A ^ A' 

pruneTmV( /3 tj l ) !->• (/3,A') 

pruneTm (V U {x}) T !->• ({3, A) 
pruneTm V (ILc: S. T) ^ (/3, A) 

pruneTm (V U {x}) T i-> ((3, A) 
pruneTm V (Ex: 5. T) ^ 00, A) 

pruneTm Vt •—> ((3, A) 
pruneTm V (s, £) (f3, A) 


pruneTm V 5 (/3, A) 

pruneTm V(ILc: S. T ) (/9, A) 

pruneTm V 5 (->• ((3, A) 
pruneTm V (Ex: 5. T) ^ ((3, A) 

pruneTm Vs (->• (/3,A) 
pruneTm V (s, t) !->• (/3, A) 

pruneTm (V U {a:}) £ !->• (/?, A) 
pruneTm V (AxT) ((3, A) 


pruneTm Vs H- (/3, A) 
pruneTm V (x • (es • e')) H- (/?, A) 


pruneTm (V U {y}) T (->• (/3, A) 
pruneT m V (x ■ (if ( v _t) e st ■ e')) Hi (/?,A) 

pruneTm Vs (->• (/3, A) 
pruneTm V (a; • (if (y.r) e st-e' )) h (A A) 

pruneTm Vt !->• (/3, A) 
pruneTm V (x ■ (if ( y _T) e st-e')) H- (/?, A) 


pruneV At/ )->• A' 


prune V • • • 


(pruning arguments t, 1 in A to V gives telescope A 1 ) 

pruneVAt/ (->• A' i/ e V fv(S) C vars(A') 
prune V (A ,x:S) (% l , y) H- A', x: S 


pruneV At/ i-> A' fv ng (s) <£_ V 
pruneV (A, x: S) (t,- 1 , s) (->• A' 


Figure 4.11: Pruning 
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Pruning uses two auxiliary relations defined in Figure 4.11. Both depend on 
a set V of variables that may occur in arguments, which will initially be fv(e) and 
will accumulate locally bound variables. 

• The relation pruneT mVf 4 (/3, A') means that t has an occurrence of (3, 
whose telescope has been pruned to A'. This works by searching t for a 
subterm [3 U * then using the following function. 

• The relation pruneVAt/ i->- A' computes the pruned telescope A' for /?, 
where A is its original telescope and t* 1 is the list of its arguments. 

These relations are partial, as pruning may fail, and the former is nondetermin- 
istic, as there may be multiple ways to prune a term. The nondeterminism does 
not matter, however, as pruning is always a most general step and can be applied 
repeatedly if necessary. 

To prune a telescope A ,x:S corresponding to the list of arguments U 1 , s, the 
preceding telescope A is pruned with the list of arguments £**. If this succeeds, 
producing A', then there are three possible cases: 

• if s is a variable y e V, whose type depends only on variables that remain in 
the pruned telescope A', then the binding x:S can be left in the telescope; 

• if s has a rigid occurrence of a variable not in V, then the binding must be 
removed from the telescope; 

• otherwise, pruning fails. 

If s has a flexible occurrence of a variable not in V, pruning fails because while 
the whole term cannot depend on the variable, it is not clear which metavariable 
projects it away, as in the a « /3 ( 71 ) example. 

Note that the potential presence of type dependencies means pruning must 
check the well-formedness of types. For example, if f3 :Ux : S. T where x occurs 
free in T, then the first argument of f3 cannot be pruned. 

For the earlier example 

0,/TT^ T,a:(T^ T) T,?\/x:(T ^ T). Wy: T. a x » x (/3 y) 

we have pruneTm {x} (x (f3 y)) (->• (/?,•), because y does not occur in the set of 
allowed variables {a;}, so prune {x} (z:T)y i-» (•) , i.e. the telescope z: T of ^ is 
pruned to the empty telescope. 
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In the metacontext 


0, /3 : IIA. T, S, ? Vr. a ■ t, 

if pruneTm (fv(e)) t t-fc (/9, A') and all the variables in T are retained in A' then 
pruning ft results in the metacontext 

0 , 7 : IIA'. T, ft :=* AA.7A' nA. T,s,?vr.a-e« t 

where 7 is a fresh variable. This restricts the telescope in a similar way to 
intersection, though it does not apply to a but a different metavariable. 

4.2.4 Metavariable simplification 

Suppose a:Yix:S. T ; how might the constraint a hd ps s be solved? One option is 
to extend the pattern fragment to cover projections, as Duggan (1998) does for 
System F w , but I take the simpler option of aggressively lowering metavariables 
to eliminate projections. In this case, replacing a with the pair (/3 0 , 0x) of fresh 
metavariables f3 0 : S, /3\: T{/3 0 } simplifies the constraint to do ~ s. 

In general, the metavariable a might be under a telescope of parameters, so 
a: IIA. E x:S. T can be replaced with 


cko : IfA. S, 07: nA. T{a 0 A}, a := AA.(o;o A, 07 A). 

Similarly, a metavariable a : Ilx : (E y : S. T). U can be uncurried to produce 
ft :Hy : S. Hz : T. [(y, z)/x\ U, which will transform the non-pattern constraint 
a (y, z) « t into the pattern ay z & t. The general case is even worse here, as a 
might have a telescope of parameters and the type of x might have parameters 
preceding the E. Thus a: nA. Hx: (nA'. E z:S. T ). U can be replaced with 

e,p:HA.Hy:(HA , .S).Hz:(HA'. T{y A'}). U{XA'.(y A',z A')}, 
a := XA.Xx.p A (AA'.x A' hd) (AA'.iA'h). 

These transformations maintain the same set of solutions thanks to the 77-rule 
for E-types, otherwise known as surjective pairing, (77 hd, ti tl) = v n. This is built 
into the definitional equality by the rule for pairs, which always 77-expands the 
terms being compared. 
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4.2.5 Problem simplification 

The problem decomposition operation P |=>- Q locally replaces a problem with 
a simpler problem without changing the rest of the metacontext. Each decom¬ 
position step can be applied in an arbitrary context. Thus P l=>- Q means that 
0,?VT.P can be replaced with @,?VT. Q. Additionally, conjunctions can be 
split into their components, replacing 0, ?VT. P A Q by 0, ?VT. P, ? VT. Q, and 
trivial problems can be removed, replacing 0, ? T with 0. First I will discuss 
the decomposition steps, then later summarise them in Figure 4.14. Steps are 
numbered for ease of reference. 

Perhaps the most basic simplification step is the removal of equations that 
are reflexive up to the definitional equality, and hence trivial: 

(s:S)/fa(t:T) ^ T (4.1) 

if 0 | T h Type 3 S={U]=T and Q\Th U 3 s=t 


//-expansion 

Given an equation between two functions, we saw in Subsection 4.1.4 that both 
sides can be //-expanded, even if the domains are not dehnitionally equal, by 
introducing twin variables. Thus a ~ Xx.t becomes ax fa t{x}. Similarly, pairs 
can be //-expanded, for example turning (a, (3) fa s into a fa s hd and (3 fa s-n,. 


(f:Ux:S. T) fa (g: Ux: U. V ) 

l=>- 

Vx:StU. (fx: T{x}) fa (gx: F{h}) 

(4.2) 

(s:Ex:S. T) fa ( f.Ex : U. V) 

l=>- 

(4.3) 

(shd: S) fa (t h 

d: U) A (stl: T{s hd}) « (£t«,: F{t HD }) 



Rigid-rigid decomposition 

A rigid-rigid equation is one where neither side is a metavariable in an evaluation 
context, so either the same head symbol appears on both sides, or the equation 
is unsolvable. For example, lix : S. T fa Tlx : U. V can be decomposed into 

S fa U A T fa V, though twins must be used because S and U might not be 

dehnitionally equal. A similar decomposition applies to E-types. 

Ux: S. T fa Ux: U. V & S fa U AVx: StU. T{x} fa V{x} {4A) 

T,x: S. T fa T,x: U. V ^ S fa U AVx: StU. T{x} fa V{x} (4.5) 

If the equation is between two eliminated variables, x ■ e fa x 1 ■ e', it can be 
decomposed into equations between the arguments contained in the evaluation 
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X 


X • • [XI x‘ ■ • 
x ■ (e s) txi x' ■ (e' t ) 
x ■ (e hd) cxi x' ■ (e' hd) 
x ■ (e tl) ixi x' ■ (e' tl) 


• (if(j,.T) e s t) ixi x' ■ e' s' f') 


T if x ~ 

x' 

x ■ e ixi x' 

• e' A s ph t 

x ■ e ixi x' 

■ e' 

x ■ e cxi x' 

■ e' 

x ■ e cxi x' 

■ e' A (Vy:B. 

A s ~ s' 

’ A t « f 


Figure 4.12: Evaluation context decomposition 


s X 1 1 (s and t are rigidly incompatible) 

c ^ d 

Ux:S. T ± Ey: U. V Ux: S. T ±c E x:S.T ±c c 1 c' 

x 

x • e 1 lit/: <9. T x-eJ-T,y:S.T x ■ e X c ac • • 
i-*lx'-es r-tlr'-eED j-ilr'-eTL si 

x ' e s _1L d ■ c hd x ‘ e s _1L x* ■ e tl x ■ e s J-\i^ y .T)x'■ e st 

x ■ e hd 1 x' ■ e tl x ■ eno JL ii ( yT )x' ■ e st i-eTLlif^.^x'-e st 

x ■ e 0 1 x' ■ e' 0 sJLi 

x ■ e 0 • ei X x' ■ e' 0 ■ e[ 11s 

Figure 4.13: Impossible constraints 
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contexts, provided they match. For example, the problem 


Vx:(S^ Ux U)t(T-> V x V).(xshd:U)& (xtw.V) 

decomposes into the equation (s: S) « (t: T). On the other hand, y hd « y tl has 
no solutions, because the projections do not match. 

The evaluation context decomposition function x-e >d x'-e', which is defined in 
Figure 4.12, computes the conjunction of problems required to make x ■ e w x' ■ e'. 
It is made available via the step 

x ■ e m x' ■ e' x ■ e txi x' ■ e' (4.6) 

The outermost eliminator in the evaluation context is decomposed first, with the 
equality of the variables (ignoring twin annotations) being checked last, to allow 
for extension to handle proof-irrelevant types. 4 

The evaluation context decomposition function is partial because a mismatched 
equation like x ^ y for distinct x and y, or y hi> sw y tl, has no solutions. Sim¬ 
ilarly, equations between dissimilar canonical constructors (such as tt « ff) are 
unsolvable. To capture this, Figure 4.13 defines the relation sit, meaning that 
s and t are rigidly incompatible, so s ~ t can never be solved. The step 

s^t l=> _L if s±t (4.7) 

allows T to be derived from such a contradiction. This definition depends on the 
fact that equations are being solved up to the intensional definitional equality: 
(x:S) ~ (y'S) can be solved up to extensionality if S has only one inhabitant. 5 

^-contraction of subterms 

Miller’s pattern condition requires that a metavariable should be applied to a 
list of variables. As the definitional equality includes ^-conversion, however, 
it is enough for the arguments to be r/-contractible to variables. For example, 
a(Xx.yx) ~ t can be r/-contracted to ay & t, potentially allowing the solution 
a := Xy.t. This motivates the steps 

P{Xx.nx} 1=^ P{n} (4.8) 

P {(n hd, ti tl) } ^ P{n} (4.9) 

that permit ^-contraction anywhere inside problems. In practice, these are useful 
only to make steps that depend on the pattern condition apply, so an implemen¬ 
tation would perform ^-contraction only when testing the pattern condition. 

Eliminations of an empty type can be equal even if the eliminated terms are not equal. 

5 Also, given proof-irrelevant types, the definition of s 1 t would need to check that the 
types were not proof-irrelevant (and could not become so after instantiation of metavariables). 
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Parameter simplification 

Parameters that do not occur in the problem can be discarded by the four steps 


Vx 

T.P 

l=>- 

P if x £ fv(P) 

(4.10) 

\/x 

S\T.P 

l=A 

P if x £ fv(P) 

(4.11) 

Vx 

S\T. P{x} 

l=>- 

Vx: 5*. P if 0 T, x: 5 F P wf 

(4.12) 

Vx 

StT. P{x} 

l=>- 

Vx: P. P if 0 T, x: P F P wf 

(4.13) 


The point of these steps is to remove unnecessary dependencies, making it eas¬ 
ier to compute the dependency-respecting permutation required when solving a 
metavariable by inversion. Again, they depend on intensionality, because exten- 
sionally a problem that quantifies over an empty type is trivially solvable. Here 
0 and T are implicitly parameters to the decomposition relation |=^, used in steps 
(4.12) and (4.13) to emphasise that P depends only on one of the twins. 

Given a pair of twins whose types are definitionally equal, they can be replaced 
with a single variable, potentially allowing further progress. For example, the 
problem \/x:SXS. s{x} ~ t{x} becomes Vx:S. s{x} ~ t{x}. 

\/x:S$f.P ^ Vx:t/.P{x,x} (4.14) 

if 0 | T F Set 9 S =[ U ]= T 

If a parameter has a E-type, it can be replaced with two parameters in order 
to eliminate projections from equations, as in metavariable simplification (Sub¬ 
section 4.2.4). For example, the problem \/x : (E y : S. T).a(x tl) ~ t{x] can 
simplify to Vy: S, z: T. a z ra t{(y, z)}. This simplification happens by the step 

Vx:(nA.E xo:S.T).P ^ (4.15) 

\/y : (nA. S),z:(HA. T{y A}). P{XA.(y A,zA)} 

4.2.6 Summary of the algorithm 

Figure 4.14 summarises the problem decomposition steps, and Figure 4.15 sum¬ 
marises the steps for transforming the metacontext, discussed in the previous 
subsections. In addition to the steps already discussed, the latter figure includes 
the symmetry step (4.26), which saves writing out symmetrical variants of all the 
other steps, and the suffix step (4.27), which allows other steps to be applied at 
an arbitrary point in the metacontext. 

Any variables that appear on the right but not on the left are implicitly 
assumed to be freshly generated, so they do not conflict with any existing names. 
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Reflexivity 

(s:S)^(t:T) \=> T (4.1) 

if 0 | T h Type 3 S ^ U ^ T and Q \ F U 3 s = t 

77 -expansion 

(f:Ux:S.T)^(g:Ux:U.V) & (4.2) 

Vx:StU. (/ x: T{x}) *t(jgx: F{x}) 

(s:Hx:S. T) « (t:T,x: U. V) ^ (4.3) 

(S»»:S) « (*«»: (/) A (stl: T{ s „„}) » («tl: F{*hd}) 

Rigid-rigid decomposition 

ILr:P. Tw ILc: U. V ^ 5 « U A VX SJ U. T{x} « F{x} (4.4) 

Ex:P. Tw Ex: U. V \=> 5 « U A Vx: U. T{x} « F{x} (4.5) 

x ■ e & x' ■ e' & x - eixx' • e 1 (4.6) 

5 « t X if s X t (4.7) 

77 -contraction of subterms 

P{Ax.ux} 1 =^ P{n} (4.8) 

P { (71 hd, 71 tl) } ^ P{n} (4.9) 

Parameter simplification 

\/x:T.P 1 =^ P if x fv(P) (4-10) 

VXPJP.P ^ Pifx^fv(P) (4.11) 

Vx:StT.P{x} & Wx:S.P iie\T,x:S\- Pwf (4.12) 

Vx:S$T.P{x} \=> Vz: T. P if 0 | T, x: T h P wf (4.13) 

\Jx:S\T.P ^ Vx:t/.P{x,x} (4.14) 

if © | T b Set 9 S =[ U ^ T 

Vx:(nA.E xo:S.T).P ^ (4.15) 

Vy : (nA. S), z: (IIA. T{yA}). P{\A.(y A, z A)} 

Figure 4.14: Problem decomposition steps 
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Solving equations by inversion (4.2.1) 

0, a: T, 5, ?VT. axi 1 ~ t e->- 0, S 0 , a :=* Axi 1 .t: T, Si (4-16) 

if S = S 0 , Si; xl l is linear on fv(f) and 0, S 0 | • h 

©,?VT. ^ 0.? 1 (4.17) 

if t ^ a ■ e' and either a e fmv sng (f) or aYi l occurs rigidly in t 

Solving flex-flex equations by intersection (4.2.2) 

0, a:fIA. T, S, ? Vr. axi 1 « ayi 1 0, /3 : flA'. T, a :=* AA./3 A', S (4.18) 
if A' = intersect A xi l Yi l and fv(T) C vars(A') 

Pruning (4.2.3) 

0, j3 : IIA. T, S, ? Vr. a ■ e ~ t ^ (4.19) 

0, 7 :nA'. T, 3 AA.q A', S, ? VT. a • e « t 
if pruneTm (fv(e)) t !->• (/?, A') 

0, ? Vr. a ■ e « t i->- 0, ? A if fv ng (t) <f_ fv(e) (4.20) 

Metavariable simplification (4.2.4) 

0, crflA. T,x:S. T (4.21) 

0, «o : IIA. S, cri: IIA. T{ao A}, & : = AA.(o;o A, a.\ A) 

Q,a:UA.Ux:(UA'.T,z:S. T). U (->• (4.22) 

0, /3:nA.n?/:(nA / .,S).n^:(nA / . T{y A'}). U{AA'.(yA',zA')}, 
a := AA.Ax.j3 A {AA 1 .x A' hd) (AA'.x A' tl) 

Problem simplification (4.2.5) 

0 ,?vr.r ^ 0 ,?vr. qhp&q (4.23) 

0 ,?vr.PAg ^ 0 ,?vr.r,?vr .q (4.24) 

0. ? X ^0 (4.25) 

Symmetry and metacontext suffix 

0,?VT.s«i ^ 0Mf0,?VT 4^m0' (4.26) 

0,S ^ 0', tS if 0 ha 0' (4.27) 

Figure 4.15: Constraint solving steps 
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4.3 Correctness 

In order to prove that unification correctly solves equational problems, I must 
first explain what it means for a problem to be solved. I will show that the 
unification logic is consistent, and that the steps of the unification algorithm are 
sound for the logic. Moreover, I will prove that every step is most general (in 
an appropriate sense). Total completeness cannot be expected, but I will show 
a partial completeness result for the pattern fragment under the assumption of 
termination. However, it is difficult to prove termination and I conclude this 
section with a discussion of the problems involved. 

4.3.1 Solved problems and logical consistency 

An equation (s: S) « (t: T) is solved if it is true according to the definitional 
equality, i.e. 0 | T b Type B S ^ U ^ T and 0 | T b U B s = t. More generally, 
a problem is solved if the equations it contains are true in the definitional equality. 
This is captured by the judgment 0 | T b P is, defined in Figure 4.16. This 
requires twins to have equal types, so they can be replaced with a single variable. 

Solved problems satisfy the expected substitution properties, proved by struc¬ 
tural induction on derivations using Lemma 4.1 and Lemma 4.2: 

Lemma 4.7. If 0 | T b <5: A and 0 | T, A, T' b P is then 0 | T, S T' b <5 P is. 

Lemma 4.8. If 9 :0 C 0' and © | T b P is then O' \9T\~ 9 P is. 

A metacontext is solved if all its hypothesised problems are solved. If a prob¬ 
lem is solved, it is true, that is, if 0 | T b P is then 0 | T b P. I will show that 
the converse holds provided 0 is solved: problems assuming only solved hypothe¬ 
ses are themselves solved. This is essentially a cut elimination or normalisation 
result, as it says that any proof of a problem can be reduced to a normal form, 
with the normal form proofs of equations being definitional equalities. 

In Subsection 4.3.2, I will show that unification steps are sound in the sense 
that they preserve provability of problems. Hence, if the algorithm steps to a 
solved metacontext, then the problems it started from must be solved. 

The potential presence of twins forces me to prove a slightly more general 
result, which allows any twins in the context to be replaced with definitionally 
equal terms. The desired result for the empty context is then an immediate 
corollary. Say that a substitution 0 | A b 5: T identifies twins if for all x:S\T e T 
we have 0 | A b Type B 8 S ^ U ^ 8 T and 0|Ab U B 8s = 8t. 
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(P is solved in 0 and T) 


| e | r h p is 

0 | r h Type 3 S^U^T 

0|rbctx e\T,x:S\- Pis © | T, x: f/ b P{x, x} is 

0 | r b T is 0 | T b Vx:5'. P is 0 | T b Vx:SJT. P is 

0 | T b Type 9 5 =[ U ]= T 

01 r b u 3 s = t ©|rbctx 

0|r b (s:S) « (t: T ) is 0 | T b (Set : Type) « (Set : Type) is 

0 |rbPis ©|rbgis 
0 I r b P A Q is 

Figure 4.16: Solved problems 

Lemma 4.9. If 0 is solved, 0 | T b P and 8 is a substitution from r to A that 
identifies twins, then 0 | A b <5 P is. 

Proof. By induction on the derivation of 0 | T b P. The absence of hypothet¬ 
ical problems or first-class quantification over problems makes it easy to show 
that the rules of the unification logic (Figure 4.6) correspond to solved problems 
(Figure 4.16). For details, see Appendix D.3.1 (page 242). □ 

Corollary 4.10. If 0 is solved and 0 | ■ b P then © | • b P is. 

Corollary 4.11 (Consistency). //0 is solved, there is no derivation o/0 | • b _L. 

A metasubstitution 0:0 jZ 0' is a solution of 0 if 0' is solved. Now if ? P e 0, 
then 0' | • b 9 P by Lemma 4.2, and hence 0' | • b 9 P is by Corollary 4.10. 

4.3.2 Soundness 

Since the algorithm works in small steps, it is easy to verify that each is type 
safe. All permutations of the metacontext respect dependency. Whenever the 
algorithm instantiates a metavariable, it does so with a term of the appropriate 
type. Moreover, every unification problem is replaced with an equivalent conjunc¬ 
tion of unification problems. Crucially, the algorithm uses heterogeneous equality 
to make it easy to represent the telescopes of equations that arise from dependent 
arguments, potentially allowing progress on some equations even if the equation 
that makes their types equal is initially blocked. Despite this, and unlike typing 
modulo, every solution is well typed up to the definitional equality, making the 
algorithm useful when mixing typechecking with elaboration. 
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Lemma 4.12. If 0 | F b P wf and P l=>- Q then 

(a) © | T h Q wf, and 

(b) © | T b Q implies © | T b P. 

Proof. By case analysis on the decomposition step. I must show that the truth 
of Q implies the truth of P, so that replacing a hypothesis ? P with ? Q leads to 
a valid metasubstitution. For details, see Appendix D.3.2 (page 245). □ 

Lemma 4.13. //0 b mctx and 0 !->• 0' then t:Q C ©'. 

Proof. By induction on the step taken, using Lemma 4.12 for problem decompo¬ 
sition. For details, see Appendix D.3.2 (page 246). □ 

Theorem 4.14 (Soundness). //0 b mctx and 0 i—>* ©' where 0' is solved, 
then t :0 jZ 0 ' is a solution of 0 . 

Proof. Follows from Lemma 4.13 by induction on the number of steps. □ 

4.3.3 Generality 

The algorithm is carefully designed to make no unforced intensional choices: that 
is, metavariables are instantiated only if the value is unique up to definitional 
equality. This corresponds to finding most general unifiers. The particular strat¬ 
egy for tackling constraints is unimportant, as the order in which constraints are 
solved does not make a difference to the result. Implementations are free to make 
alternative choices, provided all constraints are eventually dealt with. Of course, 
since vectors of equations arise from telescopes, it will usually make sense to solve 
the leftmost equations first so that later equations become homogeneous. Indeed, 
the reference implementation always works on the leftmost problem for which 
progress can be made (see Appendix C.4.6, page 235). 

Lemma 4.15 (Generality of problem decomposition). //© | T b P wf, the meta¬ 
substitution 9: 0, ? Vr. P □ ©' is a solution and P 1=^ Q, then 9 :0, ? VT. Q C 0'. 

Proof. By case analysis onPl=^ Q , supposing that 9 (VT. P) is solved and showing 
that 9 (VT. Q) is solved. For details, see Appendix D.3.3 (page 247). □ 

Theorem 4.16 (Generality). If Q 0 b mctx, the metasubstitution 0:0 O G ©' is 
a solution and 0 O ©i then there exists a cofactor /: ©i □ 0' such that 9 = (-t. 

Proof. By induction on the step taken, using Lemma 4.15 for problem decompo¬ 
sition. For details, see Appendix D.3.3 (page 248). □ 
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h pat 


c pat 


S pat T pat 
ILr: S. T pat 


S pat T pat 

E x:S. T pat 


t pat 
A x.t pat 


s pat t pat 

(s, t) pat 


a ■ e pat x ^ fv(e) 

a - ex pat 


fee pat t pat 
x ■ et pat 


n pat 
n hd pat 


n pat fmv( T) = 0 x ■ e pat s pat t pat 

ifeja pat if( y .r) x • e st pat 


Figure 4.17: Pattern fragment 

4.3.4 Partial completeness 

As I observed in the introduction, full higher-order unification is undecidable, so 
the algorithm is incomplete in general. I will show that it is complete for the 
static Miller pattern fragment, where all metavariables are applied to distinct 
bound variables, assuming it terminates. It goes beyond the pattern fragment 
in handling E-types, and postponing non-pattern problems in case they become 
solvable later. I believe that it handles a sufficiently broad class of problems to 
be useful for elaboration of a dependently typed language. 

A term t is in the pattern fragment if, for every evaluation context of a 
metavariable a ■ e in t, e consists solely of projections and applications to distinct 
variables. This is captured by the judgment t pat defined in Figure 4.17. The 
definition could be extended to allow projections of variables, provided they are 
distinct in an appropriate sense. For technical reasons in the completeness proof, 
the result type of an if-expression cannot contain metavariables. A problem is in 
the pattern fragment if all the terms it equates are in the pattern fragment. A 
metacontext is in the fragment if all its hypothesised problems are. 

To show partial completeness, I will prove that the algorithm can always take 
a step unless the metacontext is already solved or it contains a contradiction. A 
metacontext is failed if it contains 1 as a hypothesised problem. 

Lemma 4.17. Suppose 0 is a well-formed metacontext in the pattern fragment 
that is not solved or failed. Then 0 K 0' for some 0' in the pattern fragment. 

Proof. By considering the structure of the first unsolved problem in 0, demon¬ 
strating that at least one step of the algorithm must apply. The heterogeneity 
invariant means that twins or heterogeneous problems must have provably equal 
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types, and for the first unsolved problem, Corollary 4.10 implies that they must be 
definitionally equal. Hence heterogeneity will not prevent progress. For details, 
see Appendix D.3.4 (page 249). □ 

Theorem 4.18. If 0 is a well-formed metacontext in the pattern fragment, and 
0 !->■* 0' such that no more steps apply, then 0' is solved or failed. 

Proof. Follows immediately from Lemma 4.17: if 0' were not solved or failed, 
then the algorithm could take a step. □ 

4.3.5 Towards a proof of termination 

Intuitively, it seems obvious that the algorithm terminates: each step makes the 
metacontext simpler, either by decomposing a unification problem into smaller 
components, by solving a metavariable, or by replacing a metavariable with one 
or more metavariables of smaller type. 

However, it is difficult to construct a termination ordering. The conventional 
approach is to define a measure on the sizes of terms and types in the context, 
then show that each step of the algorithm reduces the measure. Abel and Pien- 
tka (2011) exhibit a suitable ordinal-based measure to show termination of their 
algorithm for LF. 

The picture is more complex for the full-spectrum dependent type theory 
I have outlined, thanks to the presence of large elimination and metavariables 
standing for types. Defining a metavariable that occurs in a type can result in 
types becoming larger, which is not the case in LF. It is thus not clear how to 
calculate the size of a metavariable. If one takes the supremum over all possible 
instantiations of a metavariable when calculating its size, then splitting up in¬ 
habitants of E-types by step (4.21) does not strictly decrease the measure in the 
resulting ordering. 

Any proof of termination will need to take account of the stratification of 
the type theory. Obviously, if the underlying theory is not strongly normalising 
then encoding a divergent term can result in non-termination of unification. How¬ 
ever, in an inconsistent system even simpler non-termination is possible. Suppose 
our type theory included the axiom that there is a type of all types, sometimes 
written Set : Set. Martin-Lof (1975) had to abandon this axiom after Girard 
demonstrated its inconsistency. Now consider the context 

ce: EX: Set. X,? a ~ (EX: Set. X, a). 
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As a has a E-type, a reasonable step is to split it into its components, giving 


Set, 7 : /3,,? ( 0 , 7 ) « (EX: Set. X, (/3, 7 )). 

Now the equation can be decomposed into 

/3: Set, 7 : /?, ? /3 ~ EX: Set. X, ? 7 fa (/3, 7 ) 
and solving EX : Set. X yields 

7 : EX : Set. X, ? 7 « (EX : Set. X, 7 ) 

which is the original problem. Applying the unification algorithm is therefore not 
guaranteed to terminate, in the presence of the Set : Set axiom. 

The lack of a termination proof for the unification algorithm (applied to the 
correctly stratified version of the theory) is rather unsatisfactory, and it is left as 
an open issue for future work. 6 It should be possible to stratify the proof in the 
same manner as the theory, demonstrating termination for small problems, then 
extending the result to the full theory with large eliminations. 

4.4 Discussion 

I have presented an algorithm for higher-order dynamic pattern unification in a 
full-spectrum dependent type theory. The approach to problem solving in this 
thesis, based on representing metavariables and problems in an ordered context, 
allows careful control over dependency and makes it easy to suspend work on one 
problem while the algorithm tries to solve another. 

The algorithm is optimised for clarity rather than performance, and I have not 
considered its algorithmic complexity. A ‘real’ implementation would probably 
need to use a representation of terms with more control over depth of evaluation, 
rather than working solely with /35-normal forms. Some care is also necessary to 
determine when to attempt each step: the reference implementation uses a fairly 
naive approach, recording the fact that no more steps apply to a given problem, 
but not the conditions under which this will change. Thus every problem must 
be examined again whenever a substitution changes its type. Similarly, rather 
than repeatedly checking to see if the types of metavariables can be simplified, 


termination of higher-order unification can be surprisingly subtle: Dowek et al. (1996) 
describe a pattern unification algorithm for which termination can fail, as Reed (2009b, §5.1.1) 
explains. The algorithm I have described is at least not vulnerable to the same counterexample! 



as in the reference implementation, projections could be eliminated only as they 
arise in unification problems. 

In this chapter, I described unification for a very restricted type theory, but the 
algorithm can be extended to support inductive types, proof irrelevance and other 
advanced features. It therefore forms the base on which to build an elaborator 
for a full-spectrum dependently typed language, in the style of Agda or Epigram. 

However, it is now time to take a different tack. In the second part of this 
thesis I will describe an extension of Haskell with dependent types. Underlying the 
elaboration algorithm for this language, as described in Chapter 7, is a constraint 
solver that makes use of the techniques for unification and type inference described 
in this chapter and those that preceded it. 
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Part II 

Haskell with dependent types 



Chapter 5 

The inch language: adding 
dependent types to Haskell 


Modern Haskell’s poorly-concealed support for dependent types is increasingly be¬ 
ing used to obtain correctness guarantees for Haskell programs (McBride, 2002). 
From the ubiquitous vectors, to well-scoped A-terms and more exotic examples, 
dependent types allow programmers to express their intentions more precisely. 
However, many of these experiments are testaments to the versatility of gener¬ 
alised algebraic datatypes, multi-parameter type classes, functional dependencies 
and type families, rather than practical programming techniques. In particular, 
working with type-level numbers and teaching arithmetic to a compiler is a com¬ 
plex, inefficient business; the syntax is ugly, error messages are convoluted and 
typechecking is sometimes difficult to predict. 

Wouldn’t it be nicer if we could write programs like the following? 

data Vec :: * — >• M —>- * where 
Nil :: Vec a Zero 

Cons :: a —>- Vec a n —>• Vec a (Sue n) 
append :: Vec a m —> Vec an—)- Vec a (m + n) 
append Nil ys = ys 

append (Cons x xs) ys = Cons x (append xs ys) 
replicate :: n (n :: N) —> a —>• Vec a n 
replicate Zero _ = Nil 
replicate (Sue n) x = Cons x (replicate n x) 

The inch language presented in this part extends Haskell with dependent func¬ 
tions (n-types), promoted datatypes (including the integers), type-level arith¬ 
metic operations and integer constraints. This is not just an attempt to turn 



Haskell into Agda or similar full-spectrum dependently typed languages. A clear 
account of the phase distinction and the operational behaviour of programs is 
needed. Working in a weaker system enables more powerful type inference. More¬ 
over, the equational theory of arithmetic is not just /3-reduction: programming 
with dependent types can be made easier by automatically solving constraints 
that depend on algebraic properties (such as the commutativity of addition). 

This chapter consists of an overview of related systems (including those based 
on current features of GHC) and an informal introduction to the syntax and 
features of inch by means of examples. Following this introduction to the high- 
level language, I will define a corresponding language of evidence in Chapter 6. 
Typechecking the evidence language is straightforward, and it is suitable as an 
intermediate language during compilation. It is very explicit (for example, all 
type abstractions and applications must be present in the syntax), so information 
omitted from inch programs must be inferred when producing the corresponding 
evidence program. This translation, called elaboration, is the focus of Chapter 7. 
I will demonstrate larger examples of the use of inch in Chapter 8. 

The description of elaboration develops the approach to the Hindley-Milner 
system studied in Chapter 2. I will not study constraint solving in detail, but 
the unification algorithm for abelian groups in Chapter 3 and the higher-order 
unification algorithm in Chapter 4 demonstrate the basic ideas. 

5.1 Related work 

No idea exists in a vacuum. In this section, I will summarise the ideas and pre¬ 
decessor systems on which inch is based, including the current state of Haskell as 
implemented in GHC, and more distantly related work. In the following section, 
I will lay out the key features of inch , comparing it to these systems as I do so. 

5.1.1 Full-spectrum dependently typed languages 

In full-spectrum dependently typed languages such as Agda (Norell, 2007), based 
on Martin-Lof Type Theory (Nordstrom et al., 1990), arbitrary terms can be 
used to index types. Numbers can be modelled as an inductive datatype and 
mathematical operations defined on them by recursion. The type theory can 
be used to prove equations needed to make a program type check. There are no 
limitations on the form of numeric expressions (to linear functions or polynomials, 
for example), since the only automatic constraint solving arises from computation 
(/3-reduction) when checking definitional equality. 
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Suppose we have the following standard definitions (in Agda syntax): 

data N : Set where 
Zero : N 

Sue : N —>• N 
_+_ : N -)• N -)• N 
Zero + n = n 
Sue m + n = Sue (m + n) 
data Vec (A : Set) : N —>■ Set where 
Nil : Vec A Zero 

Cons : V{n} —» A —y Vec An—)- Vec A (Sue n) 

Vector concatenation is easily defined by recursion on the first argument, because 
the + function is also recursive on its first argument: 

_-H-_: V{A m n} —»• Vec A m —> Vec An-) Vec A (m + n) 

Nil -H- ys = ys 

Cons x xs -H- ys = Cons x (xs -H- ys) 

However, defining vector reverse is trickier, because + does not reduce if its first 
argument is neutral and its second is canonical. Consider the following: 

reverse : V{A m} —>• Vec A m —>■ Vec A m 
reverse xs = help xs Nil 
where 

help : V{ A m n} — >• Vec A m —>• Vec An-) Vec A (m + n) 

help Nil ys = ys 

help (Cons x xs) ys = help xs (Cons x ys) 

The definition of reverse is not accepted, because m + Zero ^ m, and the second 
line of help is not accepted, because m + Sue n ^ Sue (m+ n). Instead, the user 
must insert explicit appeals to a proof of the commutativity of +. The equational 
theory of addition is not merely given by a recursive definition! 

In general, the user may need to prove many properties of the mathemati¬ 
cal operators they have defined. There has been some work on automating this, 
particularly via tactics in the interactive theorem prover Coq (Gregoire and Mah- 
boubi, 2005), but integrating this with programming can be difficult. 
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5.1.2 Dependent ML 

Xi (1998, 2007) describes Dependent ML (DML), a conservative extension of 
ML that supports “a restricted form of dependent types.” Formally, DML is a 
language schema parameterised on a constraint domain C from which type indices 
are drawn. Type checking is reduced to constraint solving in C. Instantiating 
C with a language of arithmetic expressions results in a system for type-level 
numbers, but other choices are possible, such as the theory of free algebraic terms. 
Xi and Pfenning (1998) demonstrate one application of dependent numeric types: 
the safe elimination of runtime array-bounds checks. 

The development of DML lead Xi and coworkers to design the Applied Type 
System (ATS) framework (Xi, 2004) and the ATS language (Chen, 2006). 

Dependent ML is a major inspiration for this work, but extending Haskell 
with dependent types and type-level numbers requires more than adapting Xi’s 
work to another syntax. While DML extends ML with a fixed domain of indices 
and constraints, I show how extensions to the Haskell kind system allow indexing 
by arbitrary type-level expressions, and I focus on the introduction on n-types, 
which are not supported by DML. 

One feature of DML that is absent from inch is support for effects. Since 
Haskell is more-or-less a pure language, with effects encapsulated in the 10 monad, 
there is no need for specific consideration of effects in the type system, nor for 
the value restriction. I will not discuss effects further in this thesis. 

5.1.3 Generalised algebraic datatypes 

Unlike normal algebraic datatypes, generalised algebraic datatypes (GADTs) al¬ 
low the return types of data constructors to specialise the indices of the datatype, 
by imposing additional equality constraints that must be satisfied on construc¬ 
tion and become available through pattern-matching. Thus they are a kind of 
inductive family indexed by type-level expressions. By defining suitable type 
constructors, numerically indexed types can be approximated, for example: 

data ZeroType 
data SucType :: * ->■ * 
data VecGADT :: * —>■ * —>• * where 
NilGADT :: VecGADT a ZeroType 

ConsGADT :: a —> VecGADT an—)- VecGADT a (SucType n) 

The GADT translation replaces each expression in an index of the result type 
with a variable, and imposes an equality constraint between the variable and the 


92 



original expression. This gives: 

NilGADT :: V a m .m ~ ZeroType => VecGADT a m 
ConsGADT :: V a m n. m ~ SucType n =>- 

a —> VecGADT a n —>• VecGADT a m 

The idea for GADTs dates back to a draft by Augustsson and Petersson (1994), 
although the closely related inductive families (Dybjer, 1994) have a much longer 
history in the dependent types community. A variety of names have arisen for 
essentially the same concept. Early theoretical treatments of GADTs were given 
by Xi et al. (2003) (under the name guarded recursive datatypes ) and Cheney 
and Hinze (2003) (as first-class phantom types). They were later studied by 
Sheard and Pasalic (2008) (as equality-qualified types), Simonet and Pottier (2007) 
(as guarded algebraic datatypes) and Peyton Jones et al. (2006) who christened 
them GADTs. Much subsequent work has gone in to Ending good type inference 
algorithms, especially in the presence of other advanced type system features, 
and they are well-supported in recent versions of GHC. 

Moving beyond the free algebraic equational theory of type constructors, the 
associated type families (Chakravarty et al., 2005) extension to GHC allows type- 
level functions to be defined. For example, addition can be given thus: 

type family m + n 

type instance ZeroType + n = n 

type instance SucType m + n = SucType (m + n) 

A similar approach is possible using multi-parameter type classes and functional 
dependencies (Jones, 2000). In both cases, however, the type-level programming 
is effectively untyped (as all types have kind *). There is nothing to stop one 
forming the type Z + Bool, or even declaring such nonsense as 

type instance Z + Bool = Z 


5.1.4 Haskell libraries 

McBride (2002) showed that ‘faking it’ is a viable technique for simulating nu¬ 
meric dependent types in Haskell, including type-safe vector operations and ma¬ 
trix multiplication. Subsequently, there have been numerous implementations of 
type-level numbers as libraries using existing features of Haskell. The Hackage 
repository includes the packages sized-types, type-level, type-level-numbers, 
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type-level-natural-number, numtype and undoubtedly some with more equiv¬ 
ocal names! Kiselyov (2005) discusses several possible encodings including a 
particularly ingenious decimal representation, and manages to get a long way 
without using any extensions to Haskell 98. 

Many of these libraries have arisen in response to the need for type-level 
numbers in a particular application. For example, the sized-types library is 
part of Kansas Lava (Gill et al., 2009), a DSL for hardware description. The 
ForSyDe project (Acosta, 2008) uses fixed-size vectors as part of a DSL for mod¬ 
elling computation using signals and processes. Eaton (2006) describes a linear 
algebra library that provides static guarantees about the dimensions of vectors 
and matrices, ensuring compatibility when they are multiplied. 

Impressive as these libraries are, they are all hampered by the limitations im¬ 
posed by the language, in such areas as syntax, type inference and clarity of error 
messages. Better language support for type-level data would make it possible to 
move beyond these limitations and produce a more user-friendly system. 

5.1.5 GHC TypeNats 

Recently, Diatchki (n.d.) has developed an extension to GHC that supports type- 
level natural numbers, adding a new kind Nat. The choice of natural numbers 
rather than integers is motivated by the intended applications, such as measuring 
the sizes of datatypes, but there is no fundamental reason why the alternative 
choice could not be made. Of course, natural numbers are easily recovered from 
integers and an inequality constraint, but the reverse is not so easy. 

Work is underway to support arithmetic operations on natural numbers, in¬ 
cluding addition, multiplication and exponentiation. The plan is for them to 
be described by type families that trigger special behaviour in GHC’s constraint 
solver (Vytiniotis et al., 2011). 

5.2 Features of inch 

Having described the giants on whose shoulders I am standing, I now give an 
overview of the inch language and compare it to its predecessors. The reader may 
wish to consult Chapter 8 alongside this section, for more extensive examples of 
the use of some of these features. 
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5.2.1 Down with kinds 

The Haskell kind system has been expanding for some time. From including just 
the kind * and function spaces, it has grown to encompass ‘promoted’ datatypes 
and kind polymorphism, as described by Yorgey et ah (2012). Promotion allows 
arbitrary algebraic datatypes to be used as kinds. For example, 

data Nat = Zero | Sue Nat 

allows Nat to be used as a kind, and its constructors to be used as types, as in: 

data Vec :: * —>• Nat —>• * where 
Nil :: Vec a Zero 

Cons :: a — * Vec an—)- Vec a (Sue n) 

This is a significant improvement on the essentially untyped type-level program¬ 
ming that is otherwise required with GADTs. However, the class of types that can 
be promoted is somewhat limited. In particular, GADTs cannot themselves be 
promoted. This prevents indexing a type by a GADT, which is necessary for more 
advanced dependently typed programming. For example, it is not straightforward 
to extend the traditional GADT example of well-typed terms in the simply-typed 
A-calculus so that contexts are represented by vectors. The following is rejected, 
because Vec cannot be promoted: 

data Elem :: Vec k n —>• k —> * where 
Top :: Elem (Cons a v) a 
Pop :: Elem v a —>• Elem (Cons b v) a 
data Tm :: Vec * n —> * —>• * where 
Var :: Elem v a ^ Tm v a 
Lam :: Tm (Cons a v) MTmi)(a-)5) 

App ::Tm»(fl^fe)^Tm?)a-)Tm?]5 

Now the kind system has algebraic datatypes, function spaces and polymorphism, 
so it increasingly resembles the type system, or at least the type system without 
recent extensions. Why not simplify matters by removing the distinction between 
types and kinds? This eliminates the boundary between ‘promotable’ and ‘non- 
promotable’ datatypes. It is a conceptual simplification, because users do not 
need to learn two slightly different type systems, and it means that type and kind 
checking become the same operation, which may reduce the burden of specifying 
and implementing the compiler. 
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Weirich et al. (2013) show that this identification of types and kinds gives a 
perfectly good intermediate language. They adopt the typing rule * : *, rather 
than a hierarchy of universes, because logical soundness of the system is not a con¬ 
cern. Haskell has general recursion anyway! On the other hand, type soundness 
(progress and preservation) is retained. The inch system follows their approach. 

ML lacks higher kinds (all types are of kind *), so DML distinguishes between 
types and indices, with the latter having a sort drawn from the underlying con¬ 
straint language C. It adds a single index to each datatype, and ensures types 
appear only applied to an index value. Multiple indices can be supplied as pairs. 

Integrating type-level data into a single type and kind system, as in inch , gives 
a great deal of extra expressivity. For example, the type of reflexive transitive 
closures of binary relations on a can be defined in general, then specialised: 
data RTC :: (a —where 
Embed :: r m n —> RTC r m n 
Reflexive :: RTC r n n 

Transitive :: RTC r l m —> RTC r m n —>• RTC r l n 

DML supports polymorphism over type indices, but since parametric polymor¬ 
phism in ML is restricted to types of kind *, a separate quantifier is needed. It 
uses n a : 7 . r for the universally quantified type of elements of t polymorphic in 
an index of sort 7 . Since this is a type, it can appear on the left of an arrow, 
effectively permitting a limited form of higher-rank polymorphism. Unlike the 
usual notion of a dependent function space (n-type) in type theory, this construct 
is parametric: the value a is not available at runtime and the function cannot 
eliminate it by case analysis. It thus corresponds to V in inch. 

5.2.2 Dependent functions 

How might the replicate function, which repeats a value n times to produce a list, 
be extended to return vectors? The type of the resulting vector depends on the 
integer argument, so the argument must be known statically (available during 
typechecking), but the operational behaviour of the function also requires it, so 
it must be available at runtime. It really requires a dependent n-type: 

replicate :: n (n :: N) —> a —>• Vec a n 

replicate Zero = Nil 

replicate (Sue n) x = Cons x (replicate n x ) 

The variable n is bound in the range of the n-type, just as for a universally 
quantified type scheme, but it also appears in the patterns defining the function. 
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An alternative to introducing explicit Il-types is connecting the term and 
type levels using singleton types. In this approach, a family of types is indexed 
by type-level representations of term-level data, so that each type has a single 
inhabitant. In Haskell with GADTs and datatype promotion, the example can 
be expressed using a singleton type SingNat thus: 

data SingNat:: Nat —> * where 
SingZero:: SingNat Zero 
SingSuc :: SingNat n —>• SingNat (Sue n) 
replicateSing :: SingNat n —>• a —* Vec a n 
replicateSing SingZero _ = Nil 
replicateSing (SingSuc n) x = Cons x (replicateSing n x ) 

Converting between the representations requires additional functions. Here a 
higher-rank function has been used to convert the runtime Nat into the singleton 
SingNat; an alternative approach is to use existential types (see Subsection 5.2.3). 

forget:: SingNat n —> Nat 

forget SingZero = Zero 

forget (SingSuc n) = Sue (forget n) 

remember:: Nat ->• (Vn. SingNat n ->• t) ->• t 

remember Zero / = / SingZero 

remember (Sue n) f = remember n (/ o SingSuc) 

There is some duplication and redundancy inherent in this approach, since term- 
level data must be re-expressed at the type level, but some of this can be taken 
care of by the compiler. Monnier and Haguenauer (2010) show how to convert 
from the Calculus of Constructions into a non-dependent language with singleton 
types. The Strathclyde Haskell Enhancement (McBride, 2010b) supports defining 
the type-level copy and singleton GADT for an algebraic datatype automatically, 
and the singletons library of Eisenberg and Weirich (2012) goes even further 
than this, using Template Haskell to automatically convert sufficiently simple 
term-level functions into type families. 

Dependent ML uses singletons, rather than n-types in the sense above. 

5.2.3 Dependent existential types 

A key feature of DML is its support for dependent existential types, allowing (for 
example) the type of lists to be replaced by vectors of existentially quantified 
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length. This is useful for abstraction purposes, or when the invariants being 
maintained are difficult to express at the type level. For example, the length of 
the list returned by filter depends on how many elements satisfy the predicate, 
and rather than building this into the type, another option is to return a vector 
of existentially quantified length, with a type like 

filter:: (a — > Bool) —>• Vec a n — > 3 nn . Vec a m. 

This is a powerful but complex feature, as the combination of parametric polymor¬ 
phism and existential dependent types significantly complicates type inference. 
An alternative, introduced by Laufer and Odersky (1992) and used in Haskell, is 
to associate existential values with data constructors, closing the existential pack¬ 
age when data is constructed and opening it when pattern-matching. A variable 
is existentially quantified if it does not appear in the parameters associated with 
its constructor. I use this option for inch. It is less flexible than genuine exis¬ 
tential types, as in DML, but it is also significantly simpler for type inference 
purposes and is familiar to Haskell programmers through its support in GHC. 

Xi (2007) argues that connecting existential types with data constructors leads 
to a need for too many datatypes with slightly different constraints, and Chen 
(2006, p. 23) further suggests that “indirect support to existential types is sim¬ 
ply impractical in the presence of dependent types”, using the example of the 
singleton family of integers in DML. However, higher-kinded and higher-rank 
polymorphism ameliorate the problem to an extent, as does native support for 
n-types rather than using the singleton encoding. For example, the datatype 

data Ex :: (A; —>• *) —>• * where 
MkEx ::/# —>■ Ex / 

allows any singly-indexed type to be converted into an existential. It can safely 
be eliminated via rank-2 polymorphism: 

unEx :: Va /. (Vx./ x —>• a) -4 Ex / —>■ a 

unEx g (MkEx x) — g x 

Admittedly, the usual problems with argument order for higher-kinded types will 
arise: Ex (Vec a) is conveniently the type of vectors of existentially quantified 
length, but if its arguments were reversed, Ex (Vec n) would be the rather less 
useful type of vectors of fixed length but unknown element type. In general, a 
small amount of bureaucratic constructor shuffling may be necessary, but this 
seems reasonable given the complications of type inference for existentials. 
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5.2.4 Implicit and explicit arguments 

When should it be possible to omit the argument of a function? Milner (1978) 
achieved a remarkable coincidence, as Lindley and McBride (2013) observe: 
Syntactic category Types Terms 

In source language Implicit Explicit 

Abstraction Dependent (V) Non-dependent (—>) 

Runtime Erased Present 

So neat is this coincidence that one may forget to distinguish these concepts. 

However, as more advanced type systems have been developed, Milner’s co¬ 
incidence has been stretched. On the positive side, Wadler and Blott (1989) 
introduced typeclasses, a system of implicit term-level arguments that are not 
erased at runtime. More negatively, current GHC sometimes insists on playing a 
frustrating guessing game, where it does not allow a type-level argument to be 
specified but tries to reconstruct it by unification, which is not always possible. 
That is, there are implicit static arguments that would be better made explicit. 

For example, consider the following definitions: 

type family F a 

f :: F a —> F a 
f x = x 
g :: F a —> F a 
9 — f 

The definition of g is rejected by GHC even though its type is syntactically 
identical to that of /, because it helpfully freshens a to a 0 , then fails to solve for 
the original a since F might not be injective. 1 

A folklore trick often used to solve this problem is to declare a ‘proxy type’ 
with a single phantom parameter. This allows an extra argument to be added to 
each function where the type should be passed explicitly, annotating the proxy 
constructor appropriately: 

data Proxy (a:: k) — Proxy 
f :: Proxy a4Fo->Fa 
/' x — x 
g'::\/b.F F b 
g' = f (Proxy :: Proxy b) 

1 In fact, GHC even rejects g without a type signature, presumably because it tries to recheck 
the type it has inferred and hits the same problem. 
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While this provides a workaround for the problem, it is quite invasive, as the 
original definition of the function needs to be changed, and it is syntactically 
noisy. The ability to write type application explicitly in source Haskell is long 
overdue; the only major stumbling block is deciding upon the concrete syntax. 

On the other hand, it is often desirable to omit arguments that can be re¬ 
constructed mechanically. This does not necessarily correspond to the type- 
level/term-level or compile-time/runtime distinctions: runtime terms may well 
be inferred if the types determine them. This issue has been studied extensively 
in the setting of dependently typed programming languages, in particular by Pol¬ 
lack (1990). A common approach is to allow certain arguments of functions to 
be designated implicit, 2 with the idea that they will be found automatically dur¬ 
ing type inference (typically by unification). For example, in Agda the replicate 
function can be written 

replicate : {a : Set} {n : N} —» a —* Vec a n 

replicate {n = Zero} _ = Nil 

replicate {n = Sue n} x = Cons x (replicate x) 

Now n is implicit by default at use sites, since it can usually be inferred from the 
context, even though it is critical for the runtime behaviour of the function. This 
is a big win: the compiler is writing operationally relevant parts of the program! 

Implicit arguments are written in curly braces in the type, and may be omitted 
by default in patterns and expressions, or specified by wrapping them in curly 
braces. Both positional and named variants on the notation are available. In 
{n = Sue n}, the first n specifies the implicit argument to match, and the 
second is a binding occurrence. The fact that an implicit argument can always be 
specified explicitly if necessary avoids the problems discussed above. Agda-style 
notation would allow a much neater solution to the problem discussed above: 

g" y.Vb.F b^F b 
9" =f {a = b} 

In Section 7.1, I will show how inch supports implicit argument notation. It 
adopts a slight generalisation of the Haskell syntax for quantifiers in types: a dot 
following the binder means the quantification is implicit, while an arrow means the 
quantification is explicit. Thus Va.r and n (n ::N). v are implicitly quantified, 
while V(a :: *) —y t and n n —> v are explicitly quantified. For applications, the 
Agda-style named implicit argument notation is used, as in / { a = b}. 

implicit arguments are not the same as the ‘implicit parameters’ of Lewis et al. (2000), 
which are a construct for dynamic scoping. 
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Implicit II-types 

Typeclasses provide a form of term-level implicit arguments for Haskell. Along 
with the singleton encoding, this allows an approximation of an implicit n-type: 

class ImplicitNat (n :: Nat) where 
sing:: SingNat n 

instance ImplicitNat Zero where 
sing = SingZero 

instance ImplicitNat n => ImplicitNat (Sue n) where 
sing = SingSuc sing 

A class context containing ImplicitNat n means that n is passed implicitly. It is 
meaningful even though an obvious induction shows that the predicate holds for 
every canonical Nat. An implicit version of replicate can be defined thus: 

replicatelmplicit:: ImplicitNat n =>• a —> Vec a n 
replicatelmplicit = replicateSing sing 

However, there are now three variations on a single type (Nat, SingNat and 
ImplicitNat), all of which must be understood by the programmer. Moreover, 
switching between explicit and implicit arguments is clumsy: sing :: Sing x must 
be used in place of a simple x. 

Implicit n-types are often useful in class instances. For example, in order 
to make Flip Vec n a monad, the length n must be supplied at runtime so that 
replicate can be used in the implementation of return: 

newtype Flip / x y = Flip { unFlip :: / y x) 
instance n (re :: N) . Monad (Flip Vec re ) where 
return = Flip o replicate re 

Flip xs / = Flip (help xs (unFlip o /)) 
where 

help :: Vec a m —» (a —> Vec b m) —> Vec b m 

help Nil g = Nil 

help (Cons x xs) g = Cons (vhead (g x)) (help xs (vtail o g)) 

5.2.5 Type-level numbers 

I have already shown several examples of the use of type-level natural numbers in 
measuring the lengths of vectors. For many applications involving measuring the 
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sizes of datatypes, natural numbers suffice, and they have an obvious inductive 
definition from zero and successor constructors, as shown above. Most Haskell 
libraries for type-level numbers use naturals, as does the TypeNats extension to 
GHC (Diatchki, n.d.). 

However, another choice is available: the integers. This increases expressivity 
as natural numbers can be recovered from integers using inequality constraints 
(see Subsection 5.2.7). DML (Xi, 2007) takes this choice. 

The design considerations for a language extension are different to those of 
a library. There is no restriction to ad-hoc type-level programming techniques. 
Type inference may be easier for integers, because they form an abelian group, 
allowing the unification algorithm from Chapter 3 to be used. 

Moreover, there are some use cases that rely on negative as well as positive 
integers, such as implementing a library for units of measure. Given a fixed set 
of base units, a derived unit can be represented by its integer exponents: for 
example, metres per second (m/s) could be represented by 1 as the exponent 
of metres, —1 as the exponent of seconds and 0 as the exponent of other base 
units. The NumType library of Buckwalter (2009) is one of the few libraries to 
support negative numbers for exactly this reason. In Chapter 8, units of measure 
are developed using the inch system. 

Zenger (1997) describes a Haskell-like language with types indexed by poly¬ 
nomials over the complex numbers. Grobner basis techniques can then be used 
to solve constraints. This is an interesting choice of constraint domain, but does 
not quite match most of the examples, which expect integers or natural numbers. 
This may lead to overly permissive type-checking (if constraints with no integer 
solution can be solved in C) or failures to deduce desired properties (for example, 
n > 0 does not imply n > 1). 

The prototype implementation of the inch language supports a kind Z of 
integers, plus a kind N of natural numbers that is treated as syntactic sugar for 
Z with an inequality constraint. I will focus on the addition of n-types, rather 
than numeric constraint solving, however. 

5.2.6 Supported operations 

Closely connected to the choice of numbers to represent is the signature of oper¬ 
ations that are available on them. Addition is a must for any nontrivial use of 
type-level numbers, even just appending vectors. If negative integers are permit¬ 
ted, then subtraction is also useful. If not, it is less clear what meaning (if any) 
to give subtraction; though there are several options (Runciman, 1989), perhaps 
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it is easiest to require types to be rewritten to avoid it. 

With just addition (and perhaps subtraction) one can express multiplication 
by constants and many useful linear properties, while remaining within the theory 
of Presburger arithmetic. This theory is decidable (Presburger, 1930, translated 
by Stansifer (1984)), so complete constraint solving is feasible. It should not be 
dismissed out of hand, as many useful examples can be expressed in this fragment. 

Diatchki’s TypeNats extension includes addition, multiplication and expo¬ 
nentiation on natural numbers, but omits their (partial) inverses. This leads to 
interesting challenges in designing a suitable constraint solver that is powerful 
enough to handle common constraints but also allows the user to supply proofs. 

Xi’s constraint solver for DML handles only linear constraints, though his 
formalism allows for more complex numeric expressions, and he mentions the 
possibility of postponing nonlinear constraints in the hope that they will become 
linear and hence solvable. In his subsequent work on the ATS programming 
language (Xi, 2004), he argues for the combination of programming and theorem 
proving to allow the user to supply proofs of difficult constraints. 

5.2.7 Constraints 

When working with GADTs or type families, it is frequently useful to add equality 
constraints to qualified types; indeed GADTs are implemented using equality con¬ 
straints on constructors that are made available by pattern-matching. Similarly, 
equality and inequality constraints are useful for type-level numbers. 

The encoding of propositional equality in type theory (Nordstrom et al., 1990) 
can be translated into Haskell thus (writing (~) for built-in equality constraints): 

data Id m n where 
Refl :: m ~ n =>- Id m n 

elimEq Aarnn.ld (m ~ n =£- a) —>• a 

elimEq Refl x — x 

One could abstract a over an index in the definition of elimEq, giving 

elimEq':: V(a :: t —> *) m n. Id m n — > am— > an 

elimEq' Refl x — x 

but since Haskell’s type-level function space lacks first-class A-abstraction, it is 
easier to work in the former style, using equality rather than abstraction. 

A decision procedure that produces a witness to the equality can be given by 
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decideEq ::U(m n :: Z) -A Maybe (Id m n) 


or even 

decideEq':: II (m n :: Z) -A Either (Id m n) (Id m n -A Void) 

where negation is expressed as a function to the type Void with no constructors. 
This encoding of negation is not entirely satisfactory in a non-total language, 
however, since all types are inhabited. 

Alternatively, a function to compare two integers can be given a rank-2 type: 

ifEq :: II (m n :: Z) —> (m ~ n =>• a) -A a -A a 

In the third argument, the assumption that m and n are equal is available to 
the typechecker. The kind of continuation-passing style demonstrated by ifEq 
is frequently useful to introduce additional hypotheses or eliminate existential 
type variables, showing the need for a system that integrates type-level data with 
arbitrary-rank polymorphism. Of course, it also makes use of Haskell’s laziness 
and the corresponding ease of writing control operators. 

Going beyond equalities, inequality constraints (<,<,>,>) are useful in order 
to express weak bounds. For example, they allow safe projection from a vector: 

index :: V(m :: N). n (re :: N) —> n < m =r- Vec a m -A a 

index Zero (Cons x xs) — x 
index (Sue n) (Cons x xs) — index n xs 

Similar techniques can be used to create a safe array library that eliminates 
runtime bounds checks, as Xi and Pfenning (1998) taught us. 

When used in a quantifier, the natural number kind imposes a constraint on 
the bound variable: n [n :: N). t translates to n [n :: Z). 0 ^ n =>• t. This is 
similar to (though simpler and less expressive than) DML’s notion of a ‘subset 
sort’ (Xi, 1998), which allows a new sort to be formed by restricting an existing 
sort with some constraints. 3 

Learning by testing 

A crucial feature for working with type-level data is the ability to perform type¬ 
refining dynamic tests, enabling “learning by testing” (Altenkirch et al., 2005). 
Dependently typed programming languages typically exploit dependent pattern 
3 A DML sort is similar to a Haskell kind, but restricted to terms in the index language C. 
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matching and techniques such as views (McBride and McKinna, 2004). Depen¬ 
dent pattern matching is supported by inch , as in the replicate example. 

A small extension to Haskell’s notation for guards is useful. I use curly braces 
to mark a guard, written in the constraint language, that refines the type of the 
corresponding branch. For example, the ifEq function can be implemented as: 4 

ifEq :: n (m n :: Z) — > (m ~ n =>- a) — >• a —>• a 
ifEq m n x y \ {m = n} = x 

| otherwise = y 

The runtime behaviour of such expressions is straightforward: drop the curly 
braces to obtain the usual guard. If-expressions can be handled in a similar way. 

Helping the constraint solver 

Given an incomplete constraint solver, what can the user do if a program is 
rejected because a true constraint was not solved by the system? Sometimes it 
may be possible to extend the type signature by quantifying over the additional 
constraint, requiring callers to prove it; eventually a caller may be reached that 
supplies concrete values for variables, so the constraint is easily checked. However, 
in some cases it may not be possible to quantify over the required hypothesis, for 
example if the function pattern-matches on a GADT introducing local constraints. 

One possibility is to supply additional information to the typechecker using a 
higher-rank function. For example, a term for commutativity of multiplication 

commutes :: V(m n :: Z) —>• (m * n ~ n«4d)-Pi 

would allow the user to write commutes m n x in place of an expression x that 
depends on the assumption m * n ~ n* m. The quantihcation over m and n is 
explicit, even though they are erased at runtime. This is necessary because the 
typechecker will not be able to choose appropriate arguments. 

A trusted library of properties could be implemented as ‘unsafe’ coercions. 
If the variables were available at runtime (quantified over by n rather than V), 
such properties could be ‘proved’ by writing a recursive function to perform the 
necessary induction, but in a partial language this function must be executed at 
runtime in order to ensure type safety, which is likely to be undesirable. 


4 Here ~ is the equality type constraint, = the runtime equality test and = the Haskell 
syntax for a definition! 
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Chapter 6 

A language of evidence 


In this chapter, I describe the evidence language, suitable as an intermediate 
language for a Haskell compiler. The next chapter will describe how to elaborate 
inch terms into evidence terms. The language presented here is based on System 
F c , the core language of GHC 1 , with modifications inspired by dependent type 
theory to support the new features of inch and make the presentation uniform. 

One reason for compiling via an intermediate language, rather than directly 
to a low-level language, is to ensure correctness. It is analogous to the use of an 
easily checked kernel type theory in a proof assistant such as Coq. Typechecking 
intermediate language code is straightforward, as expressions encode their own 
typing derivations, and everything is fully explicit. Terms can be checked after 
elaboration and during optimisation, leading to early detection of compiler bugs. 

A key inspiration for this chapter is the work of Weirich, Hsu, and Eisenberg 
(2013). Like them, I adopt the dangerous-sounding rule * : *, so the kind of types 
classifies itself. To a dependent type theorist, this instantly suggests paradox, 2 
but the system will permit general recursion at the type level in any case, so the 
potential paradox is irrelevant. There is no hope of proving strong normalisation 
in general, but the usual subject reduction and progress properties are maintained. 
The system does include a logic of equality, and this must be kept consistent, 
which can be achieved by keeping it weak. Coercions encode the exact amount 
of computation to be done, so there is no risk that typechecking an evidence 
term will fail to terminate. Moreover, “the point of writing a proof in a strongly 
normalizing calculus is that you don’t need to normalize it”. 3 There is no need 
to compute coercions, whereas if coercions could be bogus, they would need to 
be normalised before being relied upon to coerce values. 

1 System Fc has developed over time; the main versions are discussed in Subsection 6.7.3. 

2 The 1971 type theory of Martin-Lof (1975, 1998) was inconsistent for this reason. 

3 A saying of Randy Pollack, quoted by Altenkirch et al. (2005). 




The main feature that the evidence language adds to previous versions of 
System Fc is Il-types, allowing types to depend on a limited fragment of ‘shared’ 
runtime expressions. To enable a compact presentation of the system, I abstract 
over the possible ‘phases’ of quantification and typing judgments, and write a 
single set of typing rules covering both types and terms. This highlights the 
common structure and avoids repetition. For example, a single application rule 
replaces a multitude of rules for applying one sort of expression to another. 

Moreover, a single syntax and type system for type and term-level constructs 
allows them to have a common operational semantics, in the usual style of depen¬ 
dent type theory. This is a fundamental difference in perspective from System 
Fc- It leads to the replacement of type families (that are axiomatically defined 
and lacking operational behaviour) with honest-to-goodness case analysis. Type- 
level functions are then mere recursive definitions. There is no A-abstraction at 
the type level, and type-level functions must be saturated (fully applied), so the 
language of types is essentially first-order and elaboration is as simple as possible. 

Unlike type families, type-level functions as I define them do not support case 
analysis on types or the open world assumption. The two are not necessarily 
mutually exclusive. One could certainly imagine a system in which type families 
and true type-level (or shared type- and term-level) functions are both available. 

In Subsection 5.2.2 (page 96), I gave the example of the replicate function: 

replicate :: II (n :: N) —> a —>• Vec a n 

replicate Zero = Nil 

replicate (Sue n) x = Cons x (replicate n x) 

This uses its natural number argument both statically (as it occurs in the type) 
and dynamically (for pattern-matching at runtime). It can be seen as a single 
shared function that makes sense at the type level and the term level. 

For comparison, here is the same thing implemented using a type family and 
term-level singletons, the alternative to Il-types discussed in Subsection 5.2.2. 4 

type family Replicate (n :: N) ( x :: a) :: Vec a n 

type instance Replicate Zero = Nil 

type instance Replicate (Sue n) x = Cons x (Replicate n x) 

replicateSing :: SingNat n —>• a —>• Vec a n 

replicateSing SingZero = Nil 

replicateSing (SingSuc n) x = Cons x (replicateSing n x) 

4 The Replicate type family is rejected by GHC 7.6, because it involves a promoted GADT. 
It is forbidden by the system of Weirich et al. (2013), which does not permit the result kind of 
a type family to depend on its arguments, but this may not be a fundamental restriction. 
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The type family version can be defined directly on the kind of natural numbers, 
but the term-level version must use a singleton copy to pattern-match at runtime. 
The connection between the term and type-level functions has been lost. 

In the sequel, I introduce the syntax of the evidence language (6.1), discuss 
the key role that phase distinctions play ( 6 . 2 ) and give the type system for the 
language (6.3). I then define its operational semantics and prove subject reduction 
(6.4). Proving progress takes a little more work (6.5). Finally, I define a runtime 
erasure operation that removes types and coercions ( 6 . 6 ) and conclude with a 
discussion of possible extensions, related systems and future work (6.7). 


6.1 Syntax 

In this section, I present the syntax for the evidence language. It may be worth 
skipping quickly through this on first reading, and returning to clarify details of 
the syntax. Figure 6.1 shows the naming conventions in use in this chapter. 

Figure 6.2 gives the syntax of signatures and contexts. The signature E con¬ 
tains global top-level symbols that may appear in expressions, including type 
constructors D, data constructors K, functions / and axioms C. The context or 
telescope F, A contains variables bound locally. Contexts will later be generalised 
to metacontexts 0 , which include metavariables for use in elaboration (discussed 
in Chapter 7). 

The common syntax of expressions is shown in Figure 6.3. Unifying the syntax 
avoids redundancy, as there are unique forms for abstraction, application and 
quantification, and it simplifies the operational semantics. In Section 6.2, I will 
explain the use of phases <F, T to distinguish the different roles of types, coercions 
and terms. Saturated function applications f(S) are syntactically distinguished 
from normal application. 

For the sake of familiarity, Figure 6.4 gives subgrammars of p for type ex¬ 
pressions t,v,k, coercions 7 , 77 , runtime terms e and shared terms e. Variables 
are accounted for by a single production but I will frequently write a, b for type 
variables, c for coercion variables and x, y, z for term variables. Propositions ip 
are a subgrammar of types that represent quantified equations. 

De Bruijn (1991) showed that working with telescopes of bindings A, and 
vectors of expressions 6 corresponding to them, rather than single bindings and 
single substitution, is often a significant simplification. I write ip for a vector 
containing type expressions. 
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a, b 

type variable 

hi 

kind 

c 

coercion variable 

A 

abstraction 

e 

expression 

■e 

value type 

f 

function 

p 

expression 

i,j, k, l, m, n 

integer 

T, V 

type 

r 

erased runtime term 

V 

proposition 

V 

value expression 

# 

vector of type expressions 

x, y, z 

term variable 

U 

telescoped coercion 

C 

coercion axiom 

r,A 

context (telescope) 

D 

type constructor 

A 

abstraction 

H 

rigid constructor 

n 

dependent function space 

K 

data constructor 

E 

signature 

7> V 

coercion 

T 

type phase 

S 

vector of expressions 


phase 

£ 

shared term 

n 

non-type phase 

i 

identity substitution 




Figure 6.1: Naming conventions 


E ::= • | E,D:*k | E, K « | E, C P ip | E, / [A] :* k | E, / [A] = p k 

T, A ::= • | r,a:*r 

::= V | n | □ | A 
T ::= V|n 
n ::= p|A 


Figure 6.2: Grammar of signatures, contexts and phases 
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pV 

(Rp) ^ p' 

H 

m 

P>7 

Q 

(d)case p of bri ' 
A a-.^K.p 


I D 
I K 

I * 

I R 

q ::= 

I C 

resp uj At 
left 7 
right 7 
conga T 7 rj 
conga D 7 (771, r? 2 ) 
cong $ 77 7 
j 7@?7 

7@(Pi,P2) 
coh 7?7 
kind 7 
step p 

8 ::= -KP 

u) • | a;, (r, t\ 7) | 

(d)case ::= dcase | case 
br ::= KA^p 

Figure 6.3: 


expression 
variable 
application 
quantification 
constructor 
saturated function 
type cast 
coercion evidence 
case expression 
abstraction 

rigid constructor 
type constructor 
data constructor 
kind of types 
equality type 

coercion evidence 

axiom 

congruence 

left injectivity 

right injectivity 

congruence of T application 

congruence of □ application 

congruence of quantification 

congruence of T instantiation 

congruence of □ instantiation 

coherence 

equality of kinds 

computation step 


A (P, PO 


Grammar of expressions 
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is- 


a 

type expression (phase V) 
variable 

r*p 

application at phase $ 

(a: $ k) —>■ t 

quantification 

H 

constructor 

m 

saturated function 

T > 7 

type cast 

(d)caser of br *•* 

case expression 

c 

coercion (phase □) 
variable 

7 > ?7 

cast 

Q 

coercion evidence 

Aa: . 7 

proof abstraction 

x 

runtime term (phase X) 
variable 

e®p 

application at phase $ 

K 

data constructor 

m 

saturated function 

e > 7 

type cast 

(d)case eof 

case expression 

A o:*/c.e 

abstraction 


£ 


| £ v p 

I K 

m 

I £>J 

(d)caseeof fer* 


shared term (phase II) 
variable 

application at phase $ 
data constructor 
saturated function 
type cast 
case expression 


::= (~)kiK 2 TiT 2 | -)• 

”= • I 


Figure 6.4: Subgrammars of type expressions, coercions and terms 
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6.2 Phase distinctions and promotion 


Existing work by Yorgey et al. (2012) on System Fq, which extends System Fc 
with type-level data, is based around the idea of ‘promoting’ datatypes to the 
kind level and data constructors to the type level. By a fortuitous coincidence, 
some terms turn out to be well-kinded type expressions, but there is no formal 
relationship between well-typed terms and well-kinded types. Not all datatypes 
can be promoted, since the kind system is more restrictive than the type system, 
although work is underway to change this (Weirich et al., 2013). 

Adding II-types to a system with F ( t-like promotion is possible, adding yet 
more abstraction and application forms, and another typing judgment. However, 
factoring out the common structure makes the relationships between the phases 
clear. This is particularly true when it comes to the operational semantics: rather 
than trying to juggle separate rules for runtime terms, shared terms and type 
expressions, I can instead give a single system that covers them all. Of course, 
the purpose of the phase distinction is maintained: type expressions and coercions 
are erased at runtime, as discussed in Section 6.6. 

The evidence language distinguishes between phases given by 




phase 

V static phase (universal quantification) 

n shared phase (dependent product) 

□ proof phase (coercion quantification) 

X runtime phase (function space) 


There is a single typing judgment, annotated by the phase at which it holds. 
Phases occur on quantifiers, A-abstractions and context bindings, to indicate the 
phase at which variables are bound, and on applications, to indicate the phase 
of the quantifier. This means that the typing rules have a single rule for each 
construct, rather than a whole host of similar rules. It is not essential to unify 
these concepts; one might choose to present the phases separately. The □ phase 
must sometimes be distinguished, in order to ensure it remains consistent. In 
particular, it cannot admit case analysis or recursive functions. 

The phase annotations on typing judgments will justify the subgrammars 
given in Figure 6.4, as whenever an expression p is well-typed at phase 4>, it will 
belong to the subgrammar corresponding to <3>. 

The single syntax for quantifiers (a :‘ T> r) v subsumes universal quantifica¬ 
tion and the runtime function space: V a : r . v becomes (a : v r) —> v and r —>■ v 
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becomes (xXr) —>• v. The latter is never dependent, however, as the typing rules 
ensure x cannot be used in v, so I will often write the familiar syntax instead. 

Similarly, the single syntax for abstractions Aa: . p subsumes A-abstraction 
over terms and A-abstraction over type expressions. Again, I will write the more 
familar A x:t . e instead of Ax : W . e, but this is merely syntactic sugar. Abstrac¬ 
tions may occur only at phase X or □: there is no type-level A-abstraction. 

6.2.1 The access policy 

The fortuitous coincidence that some terms are also well-kinded type expressions 
now turns into a solid metatheoretic property: all well-typed shared terms are 
both well-typed runtime terms and well-kinded type expressions. The ‘access 
policy’ relation <F ^ 4/ expresses when things at one phase can be used at 
another. This is a partial order, defined by the following Hasse diagram: 5 


v A 



□ n 

The typing rule for variables (see Figure 6.6) 

T b ctx T 3 a:* k $ 'F 
Tb a :* k 

uses this relation: any variable bound at phase $ is accessible at phase \F. A key 
result (Lemma 6.4) extends this to show that if a typing judgment holds at phase 
4>, and <f> ^ \F, then it holds at phase T. 

6.2.2 Promoted data constructors 

Where does promotion fit in to this system? The constructor Just has type 
(a : v *, x A a) —>• Maybe a, so it seemingly expects a static and a runtime 
argument. We want to be able to use it at the type level with static arguments, 
so that Just * Bool has type Maybe*. Thus the application rule 

Tbp :* (a: # Ki) —>• k , 2 T b p' k, 

TbpV [p'/a]K2 

5 So II V and II A> while □ is lonely. 
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calculates the phase $ / 4/ at which to check the argument from the phase of 
the quantification and the phase 4/ at which the expression is being checked. The 
relativisation operator $ / 4>, pronounced ‘4> for 4F, is defined by 


// 

A 

n 

V 

□ 

X 

A 

n 

"X 

~AT 

n 

n 

n 

V 

V 

V 

V 

V 

V 

V 

□ 

□ 

□ 

□ 

□ 


When checking a runtime term, the phase of the typing judgment is X, and 
4> H X is just 4>, so arguments to runtime functions must be of the phase stated 
in their type. However, when checking in a static context, the argument must 
be known statically. This causes implicit promotion: X//^ = ^ means that 
Just* : v {x X *) —y Maybe* can be applied to Bool : v *. Since | V and 
X $ H V for all 4>, there is no way that a variable at phase X can be used in a 
type expression at phase V. 

I will usually omit the annotation on applications, writing p p' instead of p®p', 
since it is easily recovered from the type of p. It is useful for defining erasure as 
an operation on syntax rather than on typing derivations in Section 6.6. 

6.2.3 Promoted functions 

The (+) function is useful in terms, but appears also in the type of append 
for vectors. Therefore, the evidence language introduces a new style of ‘shared’ 
functions, which may occur in types and terms. 

Shared functions may appear as arguments at phase n, so type safety will 
require that reduction (in the operational semantics for shared terms) implies 
propositional equality (in the language of coercion proofs). An easy way to achieve 
this is to give a consistent operational semantics at all phases, rather than the 
different semantics of term-level functions and type families possible in Haskell. 
The operational semantics will be given in Section 6.4. 

Crucially, shared functions applications f{5) must be saturated, to distin¬ 
guish function application from normal application. This retains the injectivity 
of type-level application from System F c , and avoids introducing type-level A- 
abstractions, which would complicate type inference. 

The signature E contains function declarations / [A] : fI> k that record the 
phase of the function, the telescope A of arguments, and the resulting type /c, 
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which may depend on A. For example, the (+) function is declared at phase II 
(because it can be used in runtime terms and in type expressions) with telescope 
x A N, y A N and result type N. I will write x + y instead of (+) (x , y). 

Function definitions / [A] = p A> k are separate from declarations, because 
the body p may call / recursively. They are expanded eagerly, with a call-by- 
name semantics, and any pattern matching must be performed by explicit case 
expressions (as discussed in the Subsection 6.2.4). 

Since functions are not guaranteed to terminate, they may not appear at 
phase □, which needs to be kept consistent. This means that type safety will 
not depend on strong normalisation of functions used in types, although they 
might lead to non-termination of type inference for the source language, just as 
with type families in Haskell. Of course, it is possible to impose conditions that 
guarantee termination for a class of programs, as in Agda. 

Consider the type of the function 

vsplitAt:: Va (n :: N) . n (m :: N) —>■ Vec (m + n) a —>• (Vec m a, Vec n a) 

vsplitAt Zero xs = (Nil, ms) 

vsplitAt (Sue m) (Cons x xs) = (Cons x ys, zs) 
where (ys, zs) = vsplitAt m xs 

This type applies the function (+) to arguments at phases V and n respectively, 
building a result at phase V. As with promoted constructors, this is possible due 
to the relativisation operator, applied to the function’s telescope by the rule 

E 9 / [A] k r h 5 : A / 4/ $^ 

rh/M :® [i/A]« 

Phases act on telescopes, written A / \P, thus: 

• //* i-V • 

(A,a: # A)//^ i—^ (A/tf), a :(*//*) k 

This operation will also be used in the typing rule for dependent case branches, 
so the arguments to the constructor will be available statically. 

6.2.4 Dependent case analysis 

The replicate and vsplitAt functions rely on dependent pattern matching: case 
analysis on the N argument establishes that the result is type-correct. That is, it 
allows ‘learning by testing’ (Altenkirch et al., 2005). Recall the replicate example, 
reformulated to use a dependent case expression: 
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replicate :: Va :: * . II n :: N —>• a —)• Vec a n 

replicate n x = dcase n of 

Zero -A Nil 

Sue m —>• Cons x (replicate m x ) 

In the Zero branch, Nil needs to have type Vec a n; this is possible because a local 
constraint n ~ Zero is brought into scope. Similarly, in the Sue branch, a local 
constraint n ~ Sue m is available. In general, each branch can make use of the 
information that the scrutinee is equal to the matched constructor. 

This resembles a GADT pattern match (see Subsection 5.1.3, page 92). Indeed 
the singleton construction makes use of GADTs to encode dependent pattern 
matching. The crucial difference is that here the constraint is not an implicit 
argument to the data constructor, as with GADTs, but is separately brought into 
scope by the dependent case expression. 6 

The dcase construct of the evidence language supports dependent case anal¬ 
ysis. In the typing rule for dependent case branches, an additional variable is 
brought into scope: a proof that the scrutinee is equal to the matched construc¬ 
tor. The scrutinee must be well-typed at phase V, since it will appear in an 
equality type. This is ensured by checking it at phase II / where T is the phase 
of the case expression; the access policy gives II / ^ V. A non-dependent case 

construct is also available, allowing runtime expressions to appear as scrutinees. 

Thus the body of replicate could be translated into the evidence term 

dcase n of 

Zero (c : D n ~ Zero) —> Nil a n c 

Sue (m : n N, c : D n ~ Sue m) -A Cons a n m x (replicate (a, m, x)) c 

where the types of the constructors, after the GADT translation, are: 

Nil : (a : v *, n : v N, c : D n ~ Zero) -A Vec a n 

Cons : (a : v *, n : v N, m : v N, 

x A a, xs A Vec a m, c : D n ~ Sue m ) —>• Vec a n 

The mechanism for reconstructing the implicit arguments will be discussed in 
Chapter 7. Note that the recursive call to replicate uses an alternative syntax, 
with a comma-separated vector of arguments, to emphasise the fact that it is a 
fully-applied shared function (see Subsection 6.2.3). 

6 Of course, a GADT may appear as the scrutinee type in a dependent case expression. 
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6.3 Type system 

The evidence type system consists of the following judgments: 

E b sig E is a valid signature 

T b ctx T is a valid context 

T b p k p has type k at phase T in context T 

T b br i 4 ' v ► r br is a case branch with scrutinee type v, result type r 

T b br (e : i;) ► r br is a dependent case branch, scrutinee £ : v, result r 

T b S : A S is a vector in A 

T b tc oj : A a; is a telescoped coercion with domain A 

All judgments except E b sig are implicitly parameterised by a signature E. 

6.3.1 Well-formed signatures and contexts 

Figure 6.5 defines the signature and context well-formedness judgments. These 
check that each declared name is fresh (written #) and well-typed in the appro¬ 
priate sense, and that it is introduced at suitable phase. The signature E contains 
global top-level definitions: type constructors D, data constructors K, functions 
/ and axioms C. The context T binds variables. 

Type constructors are always static, whereas data constructors may be static, 
dynamic or shared (but not proofs). A Haskell-style datatype declaration corre¬ 
sponds to a single type constructor and a number of data constructors. System 
Fc encodes datatypes in the same way, although my use of telescopes A to collect 
type and term bindings represents a slight simplification. For GADT data con¬ 
structors, the return type is an application of the type constructor to variables, 
but the telescope will include constraints on the variables. 

As discussed in Subsection 6.2.3, functions / are separated into declarations 
/ [A] A k and definitions f [A] — p A> n, with the declaration appearing before 
the definition in the signature, in order to permit general recursion. They have 
a telescope A of parameters, which the result type k may depend on. Function 
applications will always be saturated (written f(S) where 6 is a vector in A). 

Axioms C : n (p assert that all closed instances of the proposition <p hold. For 
example, the proposition (a : v N, b : v N) —> (a+b) ~ (b + a) asserts that addition 
is commutative, but this fact is not otherwise derivable as a coercion (because 
the proof language does not permit induction). Adding this as an axiom makes it 
available when generating evidence for equalities. Since the exact form of proofs 
is unimportant, much like in Observational Type Theory (Altenkirch et al., 2007), 
any consistent axiom may be added without affecting computation. 
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E b sig 


(E is a valid signature) 


E b sig D#E E b sig K#E $ ^ □ 

a, : v Ki b ctx a, : v , A b D aj 1 : v * 

■ b sig E, D : v (a< :^**) —> * b sig E, K (a, : v «,•*, A) —> D a* 1 b sig 

/#E $ ^ □ E 9 / [A] : # k 

E b sig A b k : v * E b sig A b p :* k 

S,/[A] :* k b sig E,/[A] = p re b sig 

E b sig <7#E • b p : v * 

E, C : a </? b sig 

(T is a valid context) 

a#r rbfi: v * c#r r b ^ : v * 

T, a k b ctx T, c : D (p b ctx 

Figure 6.5: Validity of signatures and contexts 

In contexts, the validity rules require that the type of each variable is well- 
kinded. They distinguish between coercion variables c and other variables a, 
because the type of a coercion variable must be syntactically a proposition ip 
rather than an arbitrary type k, for technical reasons in the consistency proof. 

6.3.2 Well-typed terms 

Figure 6.6 defines the expression typing judgment T b p :' T ' n, meaning that p is 
an expression of type k when checked at phase T. The same judgment is given 
additional rules in Figure 6.7, as discussed in the next subsection. The variable, 
application and function rules were introduced in Section 6.2. 

Type constructors D and data constructors K are available as declared in the 
signature. In addition, there are two built-in constants: * (the kind of types) 
and heterogeneous equality (~). I will write the equality relation infix, using the 
syntactic sugar introduced in Subsection 6.3.5. 

The rule for casts p > 7 explicitly changes the type of p using the coercion 7 . 
This replaces the conversion rule, which would prevent decidability of typecheck¬ 
ing since type expressions are not strongly normalising. Casting a proof uses a 
separate rule, described in the next subsection. 



E l~ sig 

• b ctx 
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rbp :* K 


(p has type k at phase T ) 


r b ctx r b ctx r b ctx 

r 3 A : 4 k $ -7 T S3D: v k E 3 K k $ -7 ^ 

r b a :* K r b D : v k rbK:^ 


S3/[A] 

r b <5 : A/\& rbp: 4 ' (a: $ «i) ->• k 2 

r b /(<5) :* [(5/A] « r b pV :* \p'/a] k 2 
Tbp :* k 

rb T : D (t~/{' 

\& □ r b ctx 

r b p>7 :* k rb* 


r b k . * 

r,o:^br: v * 
rb(a: $ «:)4T : v * 


r b ctx 


TbH : v (a: v *) -3 ( 6 : v 


r, a K b p : n r 
Tb Aa: $ /t.p : a (a: $ «) —>• r 


rbp:% ^ □ 

T b br 0 v ► t ... r b br n v ► r 
T b casepof 6 r 0 ... &r„ r 


r b£ : n// * v 'F ^ □ 

T b 6r 0 (e : v) ► r ... T b br n (s : v) ► r 

T b dcaseeof 6 r 0 ... br n r 


r b br v ► r | (br is a well-typed case branch) 

29 K (a-i :^,A) -9 Da;* 

T, [i?,-/a/] A b p t 
r b r : v * < 3 > M- \l/ 

r bK([Voi']A) ->• P :* ► r 


r b br (g : v) ► r | (br is a well-typed dependent case branch) 

EsK / (o,- : v k<‘',A) -7 
A' = [vj/oj*] A/n, c : D £ ~ (Kl 7 *A) 
r, A' b p :* t r b r : v * $ 4 n//$ 

rbKA'^p :* (e : DuT) ► r 


Figure 6.6: Typing rules 
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Abstractions A a :®K.p are available at phases Q e {X, □}, but may not 
appear directly in types (at phase V or II). 

Case expressions were discussed in Subsection 6.2.4. They may not occur in 
proofs, since nontermination might result. Case branches are checked using two 
auxiliary judgments, T b br v ► r and T h br : fT> (e : v) ► r, meaning that 
the branch br matches a scrutinee of type v and returns an expression of type r 
at phase <F. The second judgment makes an extra assumption, that the scrutinee 
is equal to e, available in the branch. 

6.3.3 Well-typed coercions 

Figure 6.7 adds rules for well-typed coercions to the typing judgment of Figure 6 . 6 . 
Thus variables, applications and abstractions are available for coercions as well 
as other expressions. Coercions have a specialised version of the cast rule 7 > 77, 
which ensures that the result of the cast is syntactically a proposition ip'. 

The coercion syntax includes the general-purpose congruence rule resp u A t , 7 
making various structural rules derivable by asserting that [t7/A] r ~ [at/A] r. 
In particular, it means that reflexivity, symmetry, transitivity and congruence for 
dynamic functions are all derivable rules, as shown in Figure 6.9. 

Making congruence an explicit coercion form avoids the need to prove its 
admissibility (called the ‘lifting theorem’ in previous work on System Fc) and 
reduces the number of structural rules required. The system is proof-irrelevant 
so the exact form of the coercion language is unimportant. The formulation 
given here is not general enough to prove the congruence rules for application 
(conga T 7 r] and conga n 7 (771 , 772 )), quantification (cong $ 77 7 ) and case analysis 
(cong (djcasey?^*), so these must be present explicitly . 8 

The congruence rule for case analysis relies on the auxiliary definitions in 
Figure 6.8 for computing the equality proposition between two case branches. The 
operation A /X\ A' combines two telescopes that bind corresponding variables, but 
may assign them types that are only propositionally equal. It produces a single 
telescope that quantifies over variables of both types and a proof of their equality. 
Equality between two case branches br ~ br' takes the proposition that the branch 
results are equal and quantifies over the combined telescope. 

Just like in System F c , injectivity rules left 7 and right 7 allow decomposition 

7 It is sometimes useful to optimise coercions (such as replacing a coercion whose subterms 
are all reflexive with a direct appeal to reflexivity). This is possible with the resp formulation, 
but may be easier if all the structural rules are introduced separately. 

8 A more general congruence rule, allowing local parameterisation in the telescope, could be 
used to remove these. 
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(7 has type p at phase \j) 


rh 7 : D <p\ 

rh tc w : A T, A b t : v n T b 7 : D rr' ~ vv' 

r b respa; At : d [t7/A] r ~ [of/ A] r T b left 7 : D r ~ v 

r I- 7 : D rr' ~ vv' V b 7 : D ((01 :*«i) -4 n) ~ ((a 2 /c 2 ) -4 t 2 ) 

T b right 7 : D t' ~ t/ f h left 7 : D /Ci ~ k 2 


r b 7 : n («!-)• Ti) ~ (k 2 -)• t 2 ) r h ctx E 9 C P ip 

T b right 7 : D Ti ~ t 2 T b C : D p 

T h 7 : D (ri:(ai: T «i) -4 4 ) ~ (t 2 : (a 2 : T /c 2 ) H- 4 ) 

r b 77 : D (di:/ci) - (^2^2) _ 

r b conga T 7 77 : D (n v\) ~ ( t 2 v 2 ) 

T h 7 : D (ti : (ci : D </?i) — >■ «i) ~ (t 2 : (c 2 : D (p 2 ) —■» k 2 ) 
r b rji : D Pi r h 772- : D <p 2 

T b conga n 7 (771, rj 2 ) : D ~ (r 2 r/ 2 ) 


T, ai : T b Ti : v * T, a 2 : T /c 2 b t 2 : v * r b 77 : n «i ~ /c 2 

T b 7 : D (01 : T /Ci, a 2 : T k 2 , c : d a x ~ a 2 ) -4 Ti ~ t 2 


T b cong T 77 7 

: D ((01 : T /Ci) -4 T%) ~ 

((a 2 : T /c 2 ) ->■ t 2 ) 

T, ci : D p x b n : v * 

T, c 2 : D p 2 b r 2 

: v * 

T b 77 : a pi ~ p 2 

r b 7 : D (d : D Pi 

l, c 2 : D p 2 ) -4 Ti ~ t 2 

r b cong □ 77 7 

((ci: a <pi)^n)~ 

((c 2 : d <7? 2 ) -4 r 2 ) 

r b 7 : a £ ~ e' 

T b 770 : D 6r 0 « . 

.. r b 77 n : D br n « 

T b (cong (d)case777i 

*) : D ((d) cases of 677 

*) ~ ((d)case£ / of br'i ) 


r b 7 : D (/? r b 7 : D ((ai : T «i) -4 n) ~ ((a 2 : T k 2 ) -4 r 2 ) 

r b 77 : D p ~ p' r b 77 : D (d:«i) ~ (v 2 :k 2 ) _ 

rb 7 >?7 : a tp' T b 7@?7 : D [77/ai] Ti ~ [r; 2 /a 2 ] t 2 


r b 7 : D ((ci : a (pi) -4 Ti) ~ ((c 2 : D <p 2 ) -4 r 2 ) 
r b 771 : D pi r b 772 : D <p 2 

T b 7 @(t 7 i, 772) : D [771/d] Ti rv [772/c 2 ] t 2 


T b 7 : D (ti : /Ci) ~ (t 2 : k 2 ) 
r b 77 : D /Cl ~ v 
T b coh 7 77 : D Ti > 77 ~ t 2 


T b r : v k T b t ' : v /c 

T b step t : a r ~ t' 


T b 7 : D (n:/ci) ~ (t 2 :/c 2 ) 
T b kind 7 : D /Ci ~ k 2 


Figure 6.7: Well-typed coercions 
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(KA^r)« (KA'^r') ^ ((A /X\ A')) -)• (t ~ r ') 


■ tA ■ 

T, a : T k tA T', a' : T k' !->• F /A T', a : T k, a' : T /c', c : n a ~ a' 

F,x: q t /A r', x' : q t' ^ F /A F', x A r, x' A t' 


Figure 6.8: Evidence for equality of case branches 


rh 7 : a <p\ 

F b t : V k 

T h (t) : d t ~ t 


(derivable rules: 7 has type ip at phase □) 

T h 7 : D (n:/ci) ~ (t 2 :/c 2 ) 

T b sym 7 : D (r 2 : /c 2 ) ~ (ti : /Ci) 


r b 71 : D (ri:/ci) ~ (t 2 :« 2 ) 

r b 72 (t 2 :k 2 ) ~ (t 3 :/c 3 ) r b 77 : D n ~ t 2 _ r b 7 : D Vi ~ v 2 

r b 71; 72 : D (ft : «i) ~ (r 3 : /c 3 ) T b cong A V 7 ;D (Tl ->• *h) ~ (t 2 ->■ u 2 ) 


T h 7 : D (n:«i -»■ Ui) ~ (t 2 : k 2 -A u 2 ) 

rh?7 A (tJ:ki) ~ (t':k 2 ) r b 7 : D H r, * ~ H 

T b conga^7?7 : D (ti t[) ~ (t 2 T2) T b nth* 7 A ft ~ u, 


sym 7 
til 72 
cong A ?77 
conga'*" 7 77 


nth* 7 


resp • • t 

(ti) > resp ((/ci, k 2 , kind 7 ), (ft,T 2 ,7)) (a : v *, b : v a) (6 ~ Ti) 
7! > resp ((k 2 , k 3 , kind 72 ), (r 2 , r 3 , j 2 )) (a : V *, b : v a) (ft ~ b) 
resp ((ft, r 2 ,77), (ft, u 2 ,7)) (a : v *. b : v *) (a ->• 6) 
resp ((/ci, /c 2 , left (kind 7)), (ft, v 2 , right (kind 7)), 
(ti,t 2 ,7 ),(t(,tA? 7)) 

(a : v *, b : v *,x : v (a —>• 6 ), 7/ : v a) (x y) 
right ( left. . . left 7) where f|- and 77 * have n elements 


Figure 6 . 9 : Derivable rules for coercions 
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of an equation between applications or non-dependent function spaces. Instanti¬ 
ation rules 7 @r/ and 7 @( 771 , 772 ) play a similar role for dependent quantifications. 

As in the work of Weirich et al. (2013), heterogeneous equality uses the ‘E- 
interpretation’ in which an equation between expressions of different kinds implies 
that the kinds themselves are equal. This is witnessed by the kind 7 coercion. 
Also present in their work and Observational Type Theory is the coherence rule 
C 0 I 1777 , which states that casts do not change the identity of an expression. 

New in the evidence language is the step r rule, making a redex equal to its 
reduct. Thus the operational semantics, given by the kpush > relation to be defined 
in Section 6.4, is embedded in the propositional equality. The presence of step 
constructors means that the computation necessary to typecheck a term is finite. 

6.3.4 Vectors and telescoped coercions 

Figure 6.10 gives the rules for vectors and telescoped coercions. A vector 8 con¬ 
tains expressions that can be substituted for a telescope A. Thus each expression 
in the vector must be checked at the appropriate phase, with the type determined 
by substituting for the preceding telescope. 

Equality of types (~) extends to equality of vectors. A telescoped coercion 
u> represents two vectors (tj and at) along with proofs of equality for the type 
expressions they contain. Thus it consists of pairs of type expressions plus a co¬ 
ercion between them (r , v , 7), and pairs of terms (e , e') or coercions (7 , 7'). 
No proof of equality is needed for runtime terms because they cannot appear in 
types; no proof is needed for coercions because the system is proof-irrelevant. 

6.3.5 Syntactic sugar 

Some convenient abbreviations are given in Figure 6.11. Just as System Fc for¬ 
mally distinguishes between type, term and coercion application, so applications 
p®p' carry a phase, but this is easily recoverable from the type of p, so I will 
usually omit it. The presence of phase annotations on applications allows the 
erasure operation (Section 6 . 6 ) to be defined on the syntax of terms, rather than 
on typing derivations, but it is otherwise harmless to omit the annotations. I will 
write the application of an expression to a vector p 8. 

Since dynamic variables cannot occur in type expressions, thanks to the phase 
distinction, the function space (x At) —>■ v may be written r —> v, as there is 
no possibility of x occurring in v. The familiar notation \x : t . e is used for 
inhabitants of this function space. 
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(8 is a vector in A) 


rb 8 : A 


r b 8 : A 

T b ctx rbp [5/A] k 

r b • : ■ r b (S,p) : (A, a :* k ) 


T b tc cj : A 


r b ctx 

r b tc • : • 


flu is a telescoped coercion in A) 

T b tc w : A T b 7 : a r ~ v 

r b r : T [tj/A] K r b V : T [ht/A] k 
rb tc (u;,(t,u, 7 )) : (A, a : T k) 


T b tc u> : A 
rb?7 : D [tj/A]<p 
rb ri : D [^/A]<p 
T b tc (cj, (77,77')) : (A, c : D <p) 


T b tc u : A 
r b e : A [to /A] t 
rb e' : A [at/A] t 
r b tc (u, (e, e')) : (A, x : A r) 


oj, (t,v, 7 ) 
(p, p') 


tj, T 

tj, p 


u, (t,v, 7 ^ 
(P, P'i 


i-> at, v 
1 —at, p' 


Figure 6.10: Vectors and telescoped coercions 


pp' 

(->■ 

p^p' where Tbp i' 1 ' (a: $ r) —>• u 

P 8 


fp ** = • 


\(p5')p' if 5 — 5'.p' 

T —> V 

!->■ 

(xAt) —>■ v 

A x:t . e 

(->■ 

Ax : a t. e 

{r\ :k l ) ~ (T 2 : /c 2 ) 

!->■ 

(~) Ki tc 2 Ti t 2 

Ti ~ T 2 

!->■ 

(~) Ki K 2 Ti t 2 where T b Ti : v tci and T b t 2 : v tc 2 



Figure 6.11: Syntactic sugar 
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6.3.6 Meta-theoretic properties 

I will now prove some results for working with telescopes, the usual weakening and 
substitution lemmas, and a more liberal form of the substitution lemma required 
for subject reduction. Where proofs have been omitted, they are by induction on 
derivations. Writing a vector of arguments instead of a single argument for an 
application is justified by the first lemma, which I will often use implicitly. 

Lemma 6.1. Suppose T b p (A) —> r. Then T b p8 [5/A] r if and only if 
T b 5 : A//$. 

Lemma 6.2. //rh tc w : A then T b to : A and T b at : A. 

Lemma 6.3 (Weakening). Let J be an arbitrary judgment. If T . T' b J and 
T, A b ctx where the variables in A and T' are distinct, then T, A, T' b J. 

To prove the substitution lemma, I must show that judgments are preserved 
under phase increases following the access policy, as described in Subsection 6.2.1. 

Lemma 6.4 (Phase inclusion). Suppose <f> ^ 

(a) J/rbp :* K then Tbp :* k. 

(b) If T b S : A / $ then T b 5 : A // 'k. 

(c) //rb tc w : A //$ then rb tc w:A / tf. 

Proof. By induction on derivations, following from the use of the access policy 
4> ^ 4/ for the variable rule, the right-monotonicity of / for application, and the 
transitivity of 4> ^ ^ for case analysis. □ 

Lemma 6.5 (Substitution). Suppose T b 5 : A and let T' be a telescope. 

(a) //T.A.T b ctx then T, [8/ A] V b ctx. 

(b) If T, A,r'bp:^ then T, [5/A] V' b [5/A] p [5/A] «. 

(c) If r, A, r b 5' : A' then T, [5/A] T' b [5/A] 5' : [5/A] A'. 

(d) If T, A, r b tc cj : A' then T, [5/A] V b tc [5/A] u : [5/A] A'. 

Proof. By induction on derivations. The interesting case is for variables in A. 
Here 5 contains an expression that is well-typed at the phase of the variable, and 
Lemma 6.4 means it is well-typed at the phase at which the variable is used. □ 
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| $ oc \& | (checking types at phase $ may involve checking types at phase 'I ') 

$ oc \l/ 

$ oc $ $ oc V $ oc ($'/\&) 

Figure 6.12: Relevance relation 

To prove subject reduction in the presence of promotion, I will need a more 
liberal substitution lemma (Lemma 6.8), where the vector being substituted in¬ 
habits A H <F rather than A. This depends on the fact that if a typing judgment 
holds at phase <F, then it still holds when the operator is applied to part of 
the context. However, a straightforward inductive proof of this property fails, 
due to the phase change in the application rule. Instead, I must prove a more 
general property relating the phases involved (Lemma 6.7), using the ‘relevance’ 
relation $ oc ^ defined in Figure 6.12. 

Lemma 6.6. If d> oc \l/ and ^ then ^ T. 

Lemma 6.7 (Context for phase). Suppose <F oc \l/. 

(a) If T, A, F' b ctx then F, A / $, F' b ctx. 

(b) If T, A, R b p k then F, A / <F, F' b p :* k. 

(c) If r, A, R b 8 : A' // ^ then F, A // $, F' b <5 : A' // 'F. 

(d) IfF,A,F'F tc uu : A'/tf then F, A // $, F' b tc u; : A'/tt. 

Proof. By induction on derivations. In the variable case, if x n e A and 
<]V vp, then T' / <E> T by Lemma 6.6. Thus the variable rule still applies. 
For application at phase the argument is well-typed at phase <f>' // T, and 
$ oc < F / H \I/ by definition, so the result follows by induction. □ 

Lemma 6.8 (Substitution at phase). Suppose F b 5 : A / <F and fix T'. 

(a) If T, A, T' b ctx then T, [5/A] T' b ctx. 

(b) If r, A, r b p K then r, [5/A] r b [6/ A] p :* [5/A] «. 

(c) If r, A, r b 5' : A' // $ then F, [5/A] F' b [5/A] 5' : [5/A] A' / $. 

(d) If r,A,F^« : A'//$ t/ienT, [5/A]r'b tc [5/A]cu : [5/A]A'/$. 

Proof. In each case, Lemma 6.7 gives that T, A, T' b J implies F, A / <F, T 7 b J 
(by reflexivity of oc). Then the result follows from Lemma 6.5. □ 
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Each judgment has associated sanity conditions, giving admissible rules: 


Lemma 6.9 (Sanity conditions). Let E be the implicit signature. 


r b ctx 

implies 

E b sig 

Tbp :* r 

implies 

r b r : v * and T b ctx 

Tb S : A 

implies 

r b ctx 

T b tc cj : A 

implies 

r b ctx 


Proof. By induction on derivations, using the preceding results. Consider the 
application rule as an example: 

rhp : f (a: $ «q) —»■ /c 2 

rbp' 

r h pV :* [p'/a] k 2 

Induction on the first premise gives T b (a: $ «q) —> k 2 : v *, so T, a «q b k 2 : v * 
by inversion. Then Lemma 6.8 gives T b \fi'/a] k 2 : v *. □ 


6.4 Operational semantics 

In this section, I will give a small-step operational semantics for expressions. 
The reduction rules are given in Figure 6.13. These are essentially the rules 
of System F c (Sulzmann et al., 2007), with the addition of function definitions 
and dependent case analysis. The other novelty is that the rules apply to type 
expressions as well as terms. 

The syntax of values v and value types £ is: 

v ::= H 8 | (a:®K.) — >• t | Aa: . e 

£ ::= H V’ | (a: $ ft) —> r 

A value type is a value that has kind * at phase V (so A-abstraction is excluded). 
In the usual System F c fashion, expressions reduce to values that may be wrapped 
in a coercion, so there are rules to push coercions out of the way when they would 
otherwise prevent reduction. Of particular note is the push rule for the scrutinee 
of a case expression, described in Subsection 6.4.1. 

The same rules apply to phases V, II and X, but coercions (at phase □) 
are not evaluated. For type expressions, evidence that the redex is equal to 
the reduct may be required. The usual practice in dependent type theory is to 
build reduction into the definitional equality, but here there is no guarantee that 
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(p reduces to p' in one step) 


_ P_ 

P>V 


P_ _ 

p’>rj 



> case p of br/ 


case p of br'j 


kpush < 

£ —- > £ 

br ' 0 = br o > step e ... br' n = br n > step £ 
dcase £ of br 0 ... br n —> dcase s’ of br ' 0 ... br' n 


K A —>■ p e bri 1 
case K if S of br * * —> [ 5 / A] p 


K A —>■ p e bri 1 

dcase K if 5 of for,* —> [(< 5 , (K if 5 ))/A] p 


E 9 / [A] = p :* k 
m^\s/A]p 


T h 7 : a ((oi : T /ci) -A ri) ~ ((a 2 : T k 2 ) r 2 ) 

_ 7o = sym (left 7) 71 = 7@(coh (r) 70) 

(Aa: # K. e)% —> [p/a] e (vc> 7 ) T t —» v t (t> 7 0 ) >71 


T h 7 : a ((ci : n <pi) -fe Ti) ~ ((c 2 : D (p 2 ) ->■ r 2 ) 

70 = sym (left 7) 71 = 7@(p > 70, 77) 

(v > 7) n p —> v a (p > 70) > 71 

T h 7 : D ((ai: A Ki) ->• Ti) ~ {{a 2 : k K 2 ) -7- t 2 ) 

7o = s y m (left 7 ) _ 71 = right 7 _ 

(v > 7) A p —* v A (p > 70) > 71 (v > 7) > 7' —> v > (7; 7') 


kpush . 

p i 


(p reduces to p' as the scrutinee of a case expression) 


ri-7 : D D#- 

E 3 K: $ (tti -y Ki'. A) 
uj = (r*, fj, nth* 7) : a< : v -< 8 : A 
(K?f* < 5 ) > 7 > K^/ at 



Figure 6.13: Operational semantics for shared terms 
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reduction will terminate, so explicit coercions are required to retain decidability 
of typechecking. The step coercion provides the necessary evidence: 

■n i V Ti i ' V kpush , 

T r t . K T h r : K r- > r 

T h stepr : D r ~ r' 

The second premise is only to ensure that the relevant sanity property, that r ~ t' 
is well-kinded, does not depend on subject reduction. 

Computing an expression can change the type of a surrounding construction 
to something provably equal but not syntactically identical . 9 For example, sup¬ 
pose / : (a: n r) — > v and p —> e, then f(p) : [p/a]v but f(e) : [e/a\v. It is not 
straightforward to construct the coercion manipulations required to preserve the 
type, especially where there is a telescope of arguments, though the resp con¬ 
gruence can be used to prove the required equations. I take a simpler approach. 
By giving a call-by-name semantics to shared functions and lifting case analysis 
to the type level, I avoid the need for reduction in an argument position. 

In the rule for dependent case analysis, when the scrutinee takes a step, the 
branches must be coerced so that they remain type correct, since their types 
depend on a proof that the scrutinee is equal to the relevant constructor. Define 
coercion of a branch br> 7 by 

(K (A, c : D £ ~ K <5) —)• p) > 7 K (A, c! : D e' ~ K S) —>• [ 7 ; c'/c] p 

so that Y \~ hr (e : v) ► r and T h 7 : D e ~ e' implies T b br> 7 (s' : v) ► r. 

6.4.1 The push rule for scrutinees 

Each push rule has a similar form: given an expression with a coerced value that 
blocks reduction, push the coercion deeper into the term. Coerced data construc¬ 
tors may block reduction if they appear as the scrutinee of a case expression, so a 
rule is needed to push the coercion inside the arguments of the data constructor. 
For example, suppose T h 7 : D Maybe Bool ~ Maybe a and consider the scru¬ 
tinee (Just Bool True) > 7 . Pushing the coercion inside the arguments produces 
Just a (True > right 7 ), an applied constructor, so the case expression can reduce. 

The push rule for scrutinees is formulated as an extra reduction step, available 
when evaluating the scrutinee of a case expression, as shown in Figure 6.13. It 
is not available elsewhere as this would lead to nondeterminism: in particular, 
terms like (K > 7 ) p could reduce in two different ways. 

9 In Type Theory, definitional equality includes computation, so this problem does not arise. 
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Given a coerced data constructor KtA<5 > 7 , where T b 7 : D Dt/* ~ D||p 
and E 9 K A (a,- : v k, ; , A) —>• Do^’, each r* needs to be replaced with v t and 
the elements of the vector 8 coerced appropriately. The telescoped coercion 
( 7 * , Vi , nth 1 7 ) is formed for a, : v re/, then extended by 5 in A to produce 
a telescoped coercion (t*, v,-. nth* 7 ) , a; in a; : v re* *, A such that v\ *, at is the new 
vector of arguments for K. 

Recall that a telescoped coercion uj represents two vectors in some telescope T, 
given by to and at, plus proofs that they are equal. If A is a telescope extending 
T and 8 is a vector in [t7/T] A, then uj' = uj : V -< 8 : A is such that uj,uj' 
is a telescoped coercion in T, A, and a/ — 8. The telescoped coercion extension 
operation is defined thus: 

uj : T -< • : • 1 —y 

uj : T -< ( 5 , t) : (A, a : T re) H- uj', (t , r > 7, sym (coh (r) 7)) 

where uj' = uj : T -< 8 : A 
and 7 = resp (a;, uj') (T, A) k 
uj : T ^ ( 5 , p) : (A, x : Q r) 1—> uj\ (p, p > resp (ca, a;') (T, A) r) 

where a;' = a; : T -< <5 : A 

The point of this definition, upon which subject reduction will depend, is: 

Lemma 6.10 (Telescoped coercion extension). Suppose that T b tc uj 0 : A 0 , 
T b 5 : A 0 , Ai and uji = uj 0 : A 0 -< 8 : Ai. T/iera T b tc a; 0 ,o;i : A 0 , Ai. 

Proof. By induction on the definition of telescoped coercion extension. □ 

6.4.2 Subject reduction 

The point of all the work pushing coercions around is that subject reduction is 
easy to prove. It is enough to inspect the reduction steps and verify that each 
one preserves the type up to syntactic equality. 

Theorem 6.11 (Subject reduction). The operational semantics preserves types: 
ifTY-p t and p kpush > p' then T b p 1 r. 

Proof. By induction on the reduction step. I consider some illustrative cases. 

For the /3-reduction step 


(A a:*K.efp —> [p/a] e 

inversion gives T b (A a: . e) p A [p/a] r, so T b Aa: . e A (a A k) —>■ r and 

T bp H k k Then inversion on the first premise gives T,a: J /tbe A t and 
substitution (Lemma 6.5) gives T b [p/ a] e A [p/ a] r as required. 
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If the scrutinee of a dependent case expression takes a step, its type is pre¬ 
served by induction, and the definition of coercion for case branches ensures that 
the whole expression is well-typed (by the substitution lemma). 

For the dependent case analysis step 

K A —>■ p e br t 1 

dcase K -0 8 of br^ * —> [(5, (K -0 8))/ A] p 

from r b dcase K 0 <5of bri * t inversion gives that T b K-05 D-0 and 

r b bri (K-05 : D0) ► r. Suppose K has type (a,- : v k/, A) —>■ D a] j , then 
T b 0,5 : 5 ||§ : v Kj\ A) / (II H <F) by Lemma 6.1. Now substitution gives that 
r b 8 , (K 0 8 ) : [0/cq : v n/] A/II/$,c : D K 0 <5 ~ K 0A. Inversion on the rule 
for case branches gives T. [0 /cp : v Kj ] A / II, c : a K 05 ~ K LA b p A> r and 
applying Lemma 6.8 gives T b [(5, (K05))/A] p r. 

For the scrutinee reduction step 

r b 7 : D Dp# : 

E9K: $ ( fli : v k/,A) D a** 

a; = (rjjVj, nth* 7 ) : a* : v /c* -< 8 : A 

(Krf 5 )> 7 K||f at 

from r b tc (tj, Vi, nth* 7 ) : a* : v «,• and F M|Jf,5 : a, : v , A/<3>, Lemma 

6.10 gives T b tc (tj, I?*, nth* 7 ) , u; : a* : v , A / <f>. Hence Lemma 6.2 implies 
that T b-f^*, at : a, : v \ A / $ and so T b at :* Dt^b. □ 

6.5 Consistency and progress 

To prove progress, I must demonstrate the consistency of closed terms in the □ 
fragment, as the existence of a coercion between dissimilar types would lead to 
stuck terms. For example, if • by : 0 Bool ~ (Bool —> Bool) then (True > 7 ) False 
is well-typed but stuck. I will prove consistency as a corollary of a more gen¬ 
eral theorem, by defining a compatibility relation between type expressions that 
implies they have the same head constructor, and showing that provably equal 
expressions are compatible. Compatibility will require that closed expressions re¬ 
duce to head-normal forms with identical outermost constructors and compatible 
subcomponents, if they terminate at all. 

Consistency and progress depend on the usual canonical forms lemma, which 
is easy to prove thanks to the very restricted definitional equality. 
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Lemma 6.12 (Canonical forms). If v is a value and Thy r then r is a value 
type. Moreover, 

(a) If t — (a:® k) —¥ v then v is of the form e or K<5. 

(b) If t = D -0 then v is of the form K <5. 

(c) If r = * then v is a value type. 

Proof. By induction on the typing derivation. □ 

6.5.1 The definition of compatibility 

Given the reduction relation on types, obvious choices for a type equivalence 
relation include joinability or the equivalence closure of reduction. These en¬ 
sure that equivalent types have the same head constructors, so would guaran¬ 
tee consistency. However, they are too strong: for example, there is a coer¬ 
cion between (c : D (Di ~ D 2 )) —> Di and (c : D (Di ~ D 2 )) —» D 2 given by 
cong □ (Di ~ D 2 ) (Aci : D Di ~ D 2 , c 2 : D Di ~ D 2 , c' : a c\ ~ c 2 .ci), but these 
types are clearly not joinable if D, and D 2 are distinct constructors. 

Weirich et al. (2013) get round this problem by restricting the well-typed 
coercions so that they cannot use potentially inconsistent assumptions. This is 
necessarily over-restrictive, because there can be no decision procedure for con¬ 
sistency of a set of assumptions. A coercion between distinct types can exist 
in an inconsistent context, and this does not endanger consistency of the whole 
system. Instead, I define compatibility on closed types to ensure they have the 
same head constructors, and extend it to open types by considering closed in¬ 
stances. All types are equivalent in an inconsistent context, since there are no 
closed instances. Thus the existence of a coercion between two types can imply 
their compatibility. This novel approach works well for the evidence language, 
where types have a well-defined operational semantics; it would be interesting to 
see if it can be applied to System Fc with type families. 

The definitions and proofs in this section are rather technical, and can safely 
be skipped by the casual reader. The payoff comes in Subsection 6.5.4: the 
evidence language has the progress and type safety properties. I will present the 
structure of the argument here, and defer the details of proofs to Appendix D.4. 

I will define A k (tp) where p is a proposition and k is a natural number, to 
mean that p cannot be falsified within k steps. A proposition ‘really’ holds if the 
relation holds for all k. This indexing ensures that the relation is well-founded, 
and facilitates proof by induction on the index, like a step-indexed logical relation. 
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Definition 6.1 (Computational, coerced and structural type expressions). A 
type expression is computational if it is a function application f(S) or a case ex¬ 
pression (d)case r of bri *; coerced if it is a coercion t> 7 ; otherwise it is structural. 

Roughly speaking, A k {r ~ v) means that if r and v are computational, they 
can both take a step and remain related, whereas if they are structural, they both 
have the same structure and the substructures are compatible. Any coercions are 
ignored (but must be between compatible types). Moreover, the kinds of the 
expressions must be compatible. 

Definition 6.2 (Compatibility). Define A k (ip) inductively on k , provided there 
exists 7 such that • b 7 : n ip. For such a 7 , I write A fc (7 : ip) to mean that 
A k {ip) holds. The index k represents the depth of comparison to perform. A 0 (<p) 
holds for any well-typed coercion. For k > 0, A k (p) is defined based on ip. 

If <p equates two computational expressions, their reducts must be compatible: 

• Afc((ri : Ki) ~ (t 2 : /c 2 )) for Ti and r 2 computational if A fc _i(/ci ~ k 2 ), 
Ti —» vi, t 2 —> v 2 and A k _ i (v 1 ~ v 2 ). 

If ip equates two structural expressions, these must be the same structure and 
the subcomponents must be compatible: 

. A*((H:k)~(H:k)) if A,_!(«~«); 

• A fc ((Ti $ ni: Ki) ~ (r 2 *i/ 2 : re 2 )) for <F 7^ □ if A fc _i(/ci ~ k 2 ), A fc (n ~ t 2 ) 
and A k (vi ~ n 2 ); 

• Afc((Ti n 77i: K\) ~ {r 2 n r} 2 : k 2 )) if A*_i(«i ~ k 2 ), A fc (n ~ t 2 ), A*-^ : </?i) 
and A k _i(rj 2 : <p 2 ); 

• A fc (ri ->vi ~ t 2 ^ v 2 ) if A fc (ri ~ t 2 ) and A k (v x ~ %); 

• Afc((oi : T Ki) —> Ti ~ (a 2 : T /c 2 ) -A t 2 ) if A fe (/ci ~ /c 2 ) and for all l < k, 
Ai((vi: Ki) ~ (n 2 :/c 2 )) implies Ajfli/j/aj] n ~ 

• A fc ((d : D <pi) -A Ti ~ (c 2 : D (p 2 ) -A t 2 ) if A fc (</q ~ </? 2 ) and for all l < k, 
A;( 7 i : <pi) and A;(q 2 : <p 2 ) imply Aj([7i/ci] n ~ [ 7 2 /c 2 ] r 2 ). 

If one side is structural and the other is computational, the computational 
expression must reduce to a compatible structure: 

• A fc ( 7 i ~ t 2 ) where 7 i is structural and r 2 is computational if r 2 —A v 
where v is structural or coerced and A k (j\ ~ v); 
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• Afc(ri ~ r 2 ) where T\ is computational and r 2 is structural if r% —>* v 
where v is structural or coerced and A k (v ~ t 2 ). 

If either side is coerced, the coercion must be between compatible types and 
the underlying expressions must be compatible: 

• A fc (n >rj ~ t 2 ) if A *(n ~ t 2 ) and A fc _i(r 7 : «i ~ k 2 ); 

• Afc(ri ~ T 2 >rj) where T\ is not coerced if A k {j\ ~ t 2 ) and A fc _ 1(77 : «q ~ /c 2 ). 

Now the dehnition of compatibility is extended to quantified equations, by 
taking closed instances: 

• A fc ((o: T «;)—>■ <7?) if for all l < k, A i((t:k) ~ (t:/c)) implies A i([t/o\ </?); 

• A k ((c: a ip') </?) if for all l < k, A t (r] : ip') implies Ai([rj/c] </?); 

• A k((x-Ar) </?) if A*(<p). 

This dehnition extends naturally to closed telescoped coercions, requiring that 
all the coercions are between compatible types. 

Definition 6.3. Define A k (u> : A) where ■ b tc oj : A by 

• Ajt(- : • ) always; 

• A k {u, (t, v, 7 ) : A, a : T k) if A k (pj : A) and A fc (q : r ~ v); 

• A fc (u;, ( 77 , 77 ') : A, c :° </?) if A fc (cu : A) and both A k _i(rj : [tj/A]ip) and 

• A k (pj, (e, e') : A,x A k) if A k (u : A). 

For consistency and progress, the signature E must not contain any inconsis¬ 
tent axioms or malformed types (as they would invalidate consistency), or any 
undefined runtime functions (as they would invalidate progress). These condi¬ 
tions are encapsulated in the following dehnition. 

Definition 6.4 (Good declaration and signature). A signature E is good if all 
the entries in E are good, where: 

• An axiom C : D ip is good if A k (<p) and A k {ip ~ <p) for all k. 

• A constructor H r is good if A k (r ~ r) for all k. 
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• A static function declaration / [A] : T k is good if it has a unique corre¬ 

sponding definition / [A] = r : T k in E, such that A k (cu : A) implies 
A t ([tT/A] r ~ /A] r). 

• A dynamic function declaration / [A] A K j s always good, since it cannot 
occur in types. 

From now on I will implicitly assume that the signature E is good. 

6.5.2 Properties of compatibility 

I now prove that compatibility is a partial equivalence relation on types, that it 
respects computation and is a congruence. It is reflexive on well-typed expres¬ 
sions, but to prove this I must show that all well-typed coercions are compatible, 
which is the main result in the following section. 

Lemma 6.13 (Symmetry). If A k {r ~ v) then A k {v ~ t). 

Proof. By inversion on the definition. It is clear that every case is symmetric. □ 

Lemma 6.14 (Transitivity). If A k (r ~ v ) and A k {v ~ k) then A k {r ~ k). 

Proof. By induction on k and inversion on A*.(</?). For details, see Appendix D.4 
(page 250). □ 

In the usual step-indexed fashion, decreasing the step index preserves the 
relation, because strictly less of the expressions’ structures are compared. 

Lemma 6.15 (Downward closure). 

(a) If A k + 1 (<p) thenA k (ip). 

(b) If A k+1 (uj : A) then A k (u> : A). 

Proof. Part (a) is by induction on k and inversion on A fc + 1 (<p). Part (b) follows 
from part (a) by structural induction onw. □ 

To show that the step coercion preserves compatibility, use the following: 

Lemma 6.16 (Reduction preserves compatibility). If r kpush > v and A k (r ~ r) 
then Afc _\(r ~ v ). 

Proof. By induction on k and the reduction step r kpush > v. For details, see 
Appendix D.4 (page 252). □ 
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The definition of compatibility makes it a congruence for structural expres¬ 
sions and coercions. I must prove that it is a congruence for case analysis. 

Lemma 6.17 (Congruence for case analysis). If A k (e ~ e') and A fe (6r,; ~ br'f) 
for all i, then ((d)cases of br^ ~ (d)cases'of br^ ). 

Proof. By induction on k and case analysis on e and e', using Lemma 6.16. For 
details, see Appendix D.4 (page 255). □ 

To show compatibility of the kind 7 coercion, which extracts a proof that the 
kinds are equal from a proof that two types are equal, I will need the following: 

Lemma 6.18 (Compatibility of kinds). If A fc ((ri : «q) ~ (t 2 : k 2 )) holds, then 
A*_;i((ki:*) ~ (k 2 :*))- 

Proof. By induction on k and inversion on A*, ((f). □ 

6.5.3 Well-typed coercions are compatible 

Finally, I can show that the existence of a coercion between types implies their 
compatibility. Consistency is then an immediate corollary. Crucially, the logical 
unsoundness of the type language, due to the presence of general recursion and 
the paradoxical * : *, does not affect the □ fragment. General recursion is not 
available in coercions, and they may perform only a finite amount of computation. 

Lemma 6.19 (Basic Lemma). 

(a) IfT b t : v k then for all k, A fc (co 0 : T) implies A fe ([^/T] 7 ~ [^o/r] t). 

(b) If T b hr : v v ► r or T h hr : v (e : v) ► r then for all k, A k (u 0 : T) implies 
A fc ([^/r] br « [4/r] br). 

(c) IfT b 7 : D (p then for all k, A k (LU 0 : T) implies A k ([tu^/T](p) and A k ([ujo/T](p). 

(d) //rh tc w : A then for all k, A k (u 0 : T) implies A fc ([u; 0 /r]a; : A). 

Proof. By structural induction on typing derivations. Note that k is quantified 
inside the inductive hypothesis. For details, see Appendix D.4 (page 256). □ 

Theorem 6.20 (Consistency). If ■ h 7 : D (£ 0 :*) ~ (£1 : *) then £ 0 and f 1 have 
the same head constructor (that is, either £* = (aj-: $ nf) -¥ r t or £, = H ipi). 

Proof. This follows from the special case of Lemma 6.19(c) where T is empty, since 
Ai(£i ~ £ 2 ) implies £1 and £2 have the same head constructor, by definition. □ 
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6.5.4 Progress 

Thanks to the consistency proof, progress is straightforward, as in previous work. 
Type safety is an immediate corollary. 

Theorem 6.21 (Progress). If ■ he ^ r then either e is a value, e is a coerced 
value or there is some e' such that e —> el. 

Proof. By structural induction on the typing derivation. When a coerced value 
prevents reduction, Theorem 6.20 ensures that the relevant push rule applies. □ 

Corollary 6.22 (Type safety). If ■ b e X r and e —>* e' then either e' is a 
value, el is a coerced value or there is some e" such that el —> e". 


6.6 Erasure 

The erasure operation, defined in Figure 6.14, produces a runtime version ||e|| 
of an evidence term e (phase X) by removing static subterms (phases V and □). 
Similarly, an erasure operation ||<5 : A|| is defined for a vector <5 in telescope A. 

Runtime terms r are a subgrammar of evidence terms e, except that A- 
abstractions do not record their types and an additional marker _ is used to 
indicate where a subterm has been erased. This could be implemented with a 
unit type. No casts are present in runtime terms, and dependent case analysis has 
been turned into normal case analysis. The grammar of runtime terms is: 

r ::= a | A x.r \rr' \ K\ f'(r^ ) | case r of Kj A* —» r, * | _ 

Erasure uses the phase annotations on applications to avoid reconstructing 
the type of the term, but if they were not present it would be easy to define 
erasure in a typed fashion, since the evidence term encodes its typing derivation. 
Saturated function applications f{8) are not annotated with phases, so erasure 
for vectors ||<5 : A|| uses the telescope A from the declaration of the function. 

The operational semantics of runtime terms is given in Figure 6.15. It is a 
subset of the rules from Figure 6.13, omitting those related to coercions, and 
erasing the bodies of functions defined in the signature. 

The motivation for replacing erased subterms with the _ marker, rather than 
removing them (and the corresponding A-abstractions) altogether, 10 is that it sim¬ 
plifies the correspondence between the original and erased operational semantics. 
This correspondence is shown by the following lemma. 

10 Of course, subsequent optimisation of runtime terms could remove the unnecessary redexes. 
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Lemma 6.23. If ■ h e r, then either 

• e is a coerced value and ||e|| is a value; or 

• e —> e' and either ||e|| = ||e'|| or ||e|| —> ||e'||. 

Proof. If e is a coerced value, it is easy to see that ||e|| is a value. If not, Theo¬ 
rem 6.21 means that e can take a step to some e'; proceed by induction on the 
step taken. For most steps, the result follows immediately by induction or the 
fact that both e and e' are identical after erasure. The cases for /3-reduction and 
definitional expansion make use of the fact that erasure commutes with substi¬ 
tution, i.e. ||[5/A] e|| = [||<5 : A||/A]||e||. When the scrutinee of a case expression 
takes a push step, this does not change its erasure. □ 

The erasure operation described above removes all static information from 
evidence terms. In some cases it is also possible to erase dependencies without 
erasing types entirely: datatype indices are removed and Il-types become non¬ 
dependent functions. For example, in inch syntax, 

data Vec :: * —^ FT —^ * where 
Nil :: Vec a Zero 

Cons :: a — >- Vec a n —>• Vec a (Sue n) 

would be erased to 

data Vec ::*—>■ * where 
Nil :: Vec a 

Cons :: a —>- Vec a —>• Vec a 
otherwise known as the type of lists, and 
replicate :: II (n :: N) —>• a —* Vec a n 
would be erased to 

replicate :: N —> a —>• Vec a 

Thus an inch term can sometimes be converted into a Haskell term, or an evi¬ 
dence term can be converted into a System Fc-like term. However, this is not 
possible for terms containing large eliminations, where a type is computed from 
a shared term by type-level case analysis. This approach is used in the prototype 
implementation, as discussed in Chapter 8. 
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6.7 Discussion 

I conclude this chapter with comments on possible extensions to the evidence 
language, and a comparison to its predecessors. In the following chapter, I will 
show how high-level inch source code can be translated to the evidence language 
discussed in this chapter, by a process of elaboration. 

6.7.1 Representing numbers 

So far I have said a great deal about how to manage Il-types, and indeed phases 
more generally, but I have not said much about numbers. How might the evidence 
language described here be extended to support them? 

One option is to adopt the traditional algebraic datatype presentation of nat¬ 
ural numbers and integers: 

data N = Zero | Sue N 

data Z = Non Negative N | StrictlyNegative N 

Mathematical operations such as addition can be defined on these representations 
as pattern-matching functions, and the machinery in this chapter will allow them 
to be used on the type level. This is rather inefficient, though perhaps the com¬ 
piler could replace the representation with a native version after typechecking. 

However, the equational theory desired for these operations is more than the 
behaviour delivered by computation. By adding axioms to the signature, prop¬ 
erties such as the commutativity of addition can be made available as coercions, 
and hence used by the elaborator. Consistency of the system, and hence type 
safety, are ensured provided the conditions of Definition 6.4 are satisfied. 

In particular, any new axioms must be compatible, i.e. true on closed in¬ 
stances. The commutativity of addition axiom 

(a : v N, b : v N) (a + 6) ~ (b + a) 

is fine, because (a + b) ~ a) holds by computation whenever a and b are 
replaced with closed values, but a bogus axiom such as 

(a: v N) —>• a ~ Sue a 


will not be compatible. 

One problem with this approach is that some valid axioms do not satisfy the 
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compatibility relation, because they change termination properties. For example, 


(a: v Z) —>• (a — a) ~ Zero 

is not accepted, because if a is instantiated with a closed divergent term, then the 
left-hand side diverges but the right does not. This could be resolved by extending 
the definition of compatibility, so that rather than considering reduction alone, 
numeric expressions could be simplified via axioms. Consistency would then 
depend on a global property of the axioms, that they could not be used to derive 
Zero ~ Sue Zero. 

There is also more work to do on the evidence for inequality constraints. These 
can be encoded using algebraic datatypes, for example 

data m ^ n where 
Z :: Zero ^ n 

S :: nn ^ n —>• Sue m ^ Sue n 

but it might be preferable to make use of the □ fragment to record known- 
consistent (and hence erasable) inequality proofs, just as coercions are known- 
consistent equality proofs. 

6.7.2 Adding 77 -laws 

Another desirable extension of the compatibility relation is support for 77 -conversion 
of single-constructor (record) datatypes. For example, the usual fst and snd pro¬ 
jections from pairs are perfectly good shared definitions, so they can be used at 
the type level. It would be useful to support the 77 -axiom 

(a : v *, b : v *, x : v (a , b)) —>• x ~ (fst(x) , snd(x)) 

which says that any inhabitant of a pair type is equal to the pair of its projections. 
For example, this is needed to show that the type of paths in a binary relation 

data Path :: ((a, a) —>• *) —>• ((a, a) —>■ *) where 
Stop :: Path r (x, x) 

Step :: r (x, y) —* Path r (y, z) —>• Path r (x, z) 

forms an indexed monad. The following definition is accepted 

returnlx :: r (x, y) —>• Path r (x, y) 
returnlx v — Step v Stop 
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but its type is insufficiently general; it should have the type 


returnlx :: r c — > Path r c 
which requires 77 -expansion. 

As in the previous section, 77 -axioms change termination properties, because 
x might diverge, so they do not satisfy the existing definition of compatibility. 
However, as with numeric axioms, compatibility could be modified to build in 77 - 
expansion, by defining A fc ((r , t') ~ v) for computational expressions v to mean 
A *(t ~ fst(u)) and A k (r' ~ snd(u)). 

6.7.3 Related work 

System Fc(A) was introduced by Sulzmann et al. (2007) as a new core lan¬ 
guage for GHC. It is based on System F, the second-order polymorphic A-calculus 
(Reynolds, 1974; Girard et al., 1989), but adds algebraic datatypes, higher kinds 
and explicit coercions (proofs of type equality). It was motivated by the need to 
elaborate GADTs and type families, both of which can be understood as exten¬ 
sions to the equational theory of types: case analysis on GADTs introduces new 
equational hypotheses, which may be used to show the body is well-typed, while 
type families add axiomatically-dehned type-level functions. This was a major 
advance on the previous approach used in GHC, of adding GADTs to System F 
directly. The (A) parameterisation in the system represents its dependence on 
an unspecified decision procedure for checking that a context is consistent, i.e. 
that the axioms and equational hypotheses do not entail a contradiction. The 
system was subsequently revised by the authors in the light of implementation 
experience (Sulzmann et al., 2009). 

Weirich et al. (2011a) developed System Fc 2 to rectify a consistency problem 
discovered in the implementation of GHC. This resulted from the combination 
of newtypes, which introduce axioms asserting their equality with the underlying 
representation type, and type families, which can distinguish between a newtype 
and its representation. They proved that their system is consistent if type family 
declarations are non-overlapping, using an approach based on rewriting. 

Development continued with System Fq (Yorgey et al., 2012), which adds 
datatype promotion and kind polymorphism. This allows algebraic datatypes 
to be used as kinds, so type-level programming need not be entirely untyped: 
for example, a datatype of Peano numerals can be promoted to the kind level 
and used to index a GADT of vectors. However, kind equality in F<t is purely 
syntactic, so it is not possible to promote GADTs. Vytiniotis et al. ( 2012 ) tweaked 
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System F<t to support deferred type errors, by distinguishing between an ‘unlifted’ 
type of known-good equality proofs and a ‘lifted’ type of potentially bogus proofs 
that must be evaluated before use. 

Weirich et ah (2013) took the datatype promotion and kind polymorphism 
ideas to their logical conclusion, by eliminating the distinction between types 
and kinds. The evidence language described in this chapter continues in this 
direction, as it makes no distinction between types and kinds. It goes further 
in that terms and types share a common syntax and typing rules, though the 
phase restrictions mean not every expression form is available at every phase. 
Moreover, it adds II-types, allowing real dependency without the need for the 
singleton construction. 

6.7.4 Future work 

A key idea of this chapter is the use of a common syntax for terms, types and 
kinds, while the phase distinction is maintained by indexing typing judgments 
with the phase at which they apply. Variables in the context carry a phase, 
and application allows for promotion implicitly, as described in Section 6.2. An 
ordering on phases makes it possible for data at one phase to be used at another, 
thereby streamlining the presentation of II-types. 

Phases need not be confined to this system, however: they can be defined 
for any Pure Type System. The set of phases need not be {V, □,!!, X} as in 
this chapter, but could be any partially ordered set with a suitable relativisation 
operator <f> / 4/. For example, a system with two phases could model a dependent 
type theory that distinguishes between runtime and compile-time data. The 
results of this chapter illustrate the properties required for a system of phases. 
Work is ongoing to develop the theory of phases and investigate its applications. 

The novel consistency proof for coercions given in Section 6.5 takes a different 
approach to previous work, and thereby lifts a technical restriction on the use 
of potentially inconsistent assumptions in coercions between □-quantihed types. 
However, this approach relies on the common operational semantics for types 
and terms, and in particular the treatment of type functions via case analysis. It 
remains to be seen whether the method can be extended to support the notion 
of type families in System F c , which are defined axiomatically. 
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Chapter 7 


Producing the evidence: 
elaborating inch 


Broadly construed, elaboration is a type-directed process of translating a high- 
level source language into a more explicit intermediate language, inferring details 
that were originally left implicit. Section 2.4 (page 27) showed how to elaborate 
A-calculus with let-expressions into explicitly-typed System F. GHC elaborates 
Haskell programs into System Fc, which adds algebraic datatypes, higher kinds 
and type equality constraints to System F. Dependently typed languages such 
as Epigram are explained by elaboration into a type theory, with the elaborator 
synthesising implicit arguments and solving higher-order unification problems. 

Following the Curry-Howard correspondence, elaboration of programming lan¬ 
guages is closely connected to generating proof objects from proof scripts in in¬ 
teractive theorem provers (such as Coq with its core language Gallina). Here, 
the primary motivation is ensuring correctness through the de Bruijn criterion. 
A well-understood kernel theory, with simple typechecking, allows the output 
from complex tactics and decision procedures to be independently rechecked. 
Likewise, GHC is an extremely complex program, and the ability to easily type- 
check programs in the intermediate language is crucial to debugging the compiler. 
Moreover, the intermediate language provides a good basis for implementing op¬ 
timisations, as all the typing information is available explicitly. 

In this chapter, I will describe the process for elaborating inch programs into 
the evidence language defined in the last chapter. I begin by introducing ‘type 
schemes’, which decorate evidence language types with information on implicit 
arguments (7.1), inspired by the work of Pollack (1990). The formal syntax 
of the inch language (7.2) includes a large fragment of the informally presented 
syntax. Instead of giving this a type system directly, I supply a non-deterministic 



elaboration system that relates inch terms to evidence terms (7.3). 

I then explain how partial knowledge and progress can be represented (7.4), 
and describe a definite (and necessarily incomplete) algorithm for elaboration 
(7.5). This is based on the work on type inference in Part I, where unification 
variables and unsolved constraints are explicitly represented using metacontexts. 
The algorithm reduces elaboration to constraint solving in the underlying evi¬ 
dence language. Designing a constraint solving algorithm is a complex task in 
itself. I will specify its required properties and describe it at a high level, but I 
will not describe constraint solving in detail. 

Elaboration of case expressions, which is the basis for the treatment of pattern¬ 
matching definitions, is somewhat involved and is therefore postponed (7.6). The 
chapter concludes with some contextualising remarks (7.7). 

7.1 Type schemes 

As discussed in Subsection 5.2.4 (page 99), it is desirable to have finer-grained 
control over which arguments are automatically inferred than the current Haskell 
policy of forcing V-bound arguments to be implicit and other arguments to be 
explicit. Instead, constants and variables in the context will be assigned a type 
scheme a , consisting of a quantified type with annotations indicating whether 
each argument is implicit (q) or explicit (: e ). The grammar of schemes is given 
in Figure 7.1. For example, the type scheme of the equality constructor is 

: (a *,b *,x a,y b) * 

meaning that the first two arguments are implicit and the last two are explicit, 
thereby justifying the usual use of (~ ) as a binary operator. The usual definition 
of vectors gives rise to the following type schemes: 

Vec : (a *, n ^ N) —>• * 

Nil : (a *, n :■ N, c : t D n ~ Zero) —>• Vec a n 

Cons : (a A*, n :) N,m A N, 

x A a, xs A Vec a rn, c n ~ Sue m ) —> Vec a n 

I will not give formal rules for elaborating source language datatype declarations 
into constructors with the appropriate type schemes. 

Quantification over proofs (at phase □) will always be implicit, because co¬ 
ercions are not written in the source language. On the other hand, dynamically 
quantified variables will be explicit, as they cannot be determined by unification 
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r, a 


"= T I (« -t °') ° I (« ■? r)^a 
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^ (a: $ r) -T [aj 


[• J H- • 

[x :f a. AJ H- x |_#J, L^J 

[a :f r, AJ H- a r, |_AJ 


Figure 7.1: Grammar and erasure of schemes and annotated telescopes 

constraints. Typeclasses can be seen as a form of implicit dynamic quantification, 
with an alternative strategy for finding the corresponding arguments, based on 
instance search rather than unification. This idea underlies Agda’s support for 
instance arguments (Devriese and Piessens, 2011). I will not consider typeclasses 
further, but it is straightforward to handle them using the elaboration framework. 

Like schemes, telescopes can be annotated to indicate whether the argument 
is implicit or explicit, writing A instead of A. Erasing the annotations produces 
a type or telescope in the evidence language, written [crj or [AJ and defined in 
Figure 7.1. I will assume that the signature E assigns type schemes to constructors 
H and annotated telescopes to shared functions /. In general, I will elide the 
distinction between a quantified type (a n) —>• r and an explicitly-quantified 
type scheme (a :f k) — > r. 

Quantifying a scheme over a telescope (A) — y a and the relativisation operator 
A H $ extend the definitions on evidence expressions in the obvious way. 

I do not extend the type system of the evidence language itself. This avoids 
complicating the metatheory with details of implicit arguments. Rather, schemes 
are a tool for explaining how elaboration should generate explicit evidence terms. 

To obtain good inference behaviour, the elaboration algorithm should never 
attempt to ‘guess’ type schemes, only propagate them through bidirectional type 
inference. This avoids questions of how to unify type schemes. For this reason, 
the domain of an implicit quantification is always a type rather than a scheme. 

Following the Agda convention, the application syntax p{a= p'} is used to 
supply explicitly an argument that is usually implicit, with name a. This means 
type schemes cannot always be treated as equivalent up to a-conversion, as names 
may appear outside the scope in which they are bound. 
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inch expression 

a 

variable 

PP' 

explicit application 

p{a=p'} 

implicit application 

V(a: k) —>■ t 

explicit V quantification 

n(a:r) —)■ v 

explicit n quantification 

t — y v 

function type (explicit X quantification) 

H 

constructor 

m 

saturated function 

p:a 

type ascription 

Xx . p 

abstraction 

let x = p in p' 

let binding 


unknown 

Figure 7.2: 

Grammar of inch expressions 


7.2 Formal syntax of inch 

The grammar of inch is presented in Figures 7.2 and 7.3. Like the evidence 
language, there is a common syntax for expressions p, but I will usually use 
t, v or k for types and s or t for runtime terms (according to the respective 
subgrammars). While the presentation using a common syntax is compact, it is 
inessential and one may use different syntaxes for the term and type levels. 

The main additions, compared to the evidence language, are: let-expressions; 
the ability to ascribe a type scheme to an expression, written p : cr; and the 
‘unknown’ marker _, which asks for a value to be inferred by the elaborator. 
All coercion proofs are omitted (as they will be generated by constraint solving, 
not supplied by the user). The inch syntax uses upright Greek letters such as p, 
where the evidence syntax would use the italic p. 

The syntax of inch type schemes cr is deliberately chosen to resemble Haskell 
syntax. It will be translated by elaboration into the evidence language type 
schemes of Section 7.1. There is no explicit quantifier at phase □, and the implicit 
quantifier does not bind a variable, because proofs are invisible in the source 
language. There is no implicit quantifier at phase X, because no constraints would 
be able to determine the value of a dynamic argument (absent typeclasses). 

The source syntax should allow type ascriptions on quantifiers to be omitted, 
but this can be dealt with by inserting _ markers as necessary. For example, the 
universal quantifier V a.cr can be desugared into V(a:_). cr before being elaborated 
into the evidence type scheme (a k) —> a. 

The treatment of (dependent) case analysis is postponed to Section 7.6. 
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cr 


V(a: k). a 
V(a: k) ->• a 
II(a:T) ->■ cr 
II(a:T). a 

T (T 

o 7 —^ cr 


a 

xv 

T{a = v} 
V(a: k) —>• T 
II(a:T) —>• v 

H 

/(«) 
t: a 


tp 

t{a=p} 

K 

m 

t: a 
Ax. t 

let x = s in t 


6 ::= ■ | 6, p | 5, {a= p} 


inch type scheme 

implicit V quantification 

explicit V quantification 

explicit II quantification 

implicit II quantification 

constraint (implicit □ quantification) 

function type (explicit X quantification) 

type 

inch type 
variable 

explicit application 

implicit application 

explicit V quantification 

explicit II quantification 

function type (explicit X quantification) 

rigid constructor 

saturated function 

type ascription 

unknown 

inch term 
variable 

explicit application 
implicit application 
data constructor 
saturated function 
type ascription 
abstraction 
let binding 
unknown 


Figure 7.3: Grammar of inch type schemes, types, terms and vectors 
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7.3 Non-deterministic elaboration 

I start by giving a non-deterministic presentation of elaboration that relates inch 
syntax to well-typed evidence terms, following the account of elaboration for 
implicit argument synthesis in the Calculus of Constructions by Luther (2003). 
The non-deterministic presentation resembles a type system for inch , as it allows 
types and evidence terms to be assigned, but does not indicate how they are to 
be discovered. I will then show how missing information can be reconstructed 
and give a deterministic algorithm. 

The non-deterministic elaboration rules are presented in the Figures 7.4-7.6. 
Intuitively, elaboration is built out of structural rules, which preserve the struc¬ 
ture of the input term, and wrapping rules, which add information missing from 
the input. It is a kind of ‘embedding’ of inch terms into evidence terms. The 
judgments defined are: 

• T h pp a, meaning that the inch expression p can be elaborated into 
the evidence expression p with scheme cr; 

• T b 6 5 : A. meaning that the inch vector 6 elaborates to <5 in the 

telescope A, by inserting implicit arguments; 

• T h a cr, meaning that the inch type scheme cr elaborates to the 

evidence type scheme cr; and 

• T b e : a -< el : cr', meaning that the type scheme a is subsumed by a' and 
if e : cr then e' : cr'. 

7.3.1 Non-deterministic elaboration of expressions 

The judgment Tl-p^p: $ ( 7 , defined in Figure 7.4, means that in a context T, 
the inch expression p interpreted at phase <F can be elaborated to the evidence 
term p with type scheme cr. This judgment is not defined at phase □ because 
coercions do not appear in the source language. It uses annotated contexts T so 
that variables record whether they were explicitly bound, and hence in scope for 
the source language, or implicitly bound, and hence inaccessible. 

Most of the elaboration rules simply preserve the structure of the source lan¬ 
guage expression in the target language. An important exception is the ‘magic’ 
rule for implicit A-abstraction 

r. a :f r b t e : A cr 
rbt'wAa: <E> r.e: A (a:f r) —>■ cr 
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r b p -w p a\ (p can elaborate to p with scheme a at phase 4/ e {V, II,X}j 


Jfj b ctx 

T3a:t<J 

[rj b ctx 

E9H:% ^ 

T b a ^ a 

rbH^H:% 

E9/[A]:% $ M- 

rb6^(5:A//^ 

rhp™,,:* (A)-xt 
rb6-w(5:A/\f 

n-/(S)~./(J):*[i/A]K 

rb P 6^^ A [5/A] a 

r b K -w k : V * 

r b T r : V * 

r, a !g /c b T T : v * 

r,x:frbv^v: v * 

T b V(a: k) — >• x -w (a: v «) — >• r : v * 

T b II(x:t) -4- v (x: n T) — u : v * 

r b t t : v * rbu-w 

v : v * |_FJ b ctx 

rbT4U^r-> u : v * 

f b * * :% 

|_rj b ctx 

: v (a :* *) 

-> (t ; j *) -> a -> i * 

r, x t b t -w e : A a 

T, a :f t b t e : A a 

T b Ax . t Ax : # r . e : A (x r) — >• a 

rbt'^Aa: $ T.e: A (a:fT)->(T 

T b s w e : A a 

r b a o- 

I\ x : A a b t e' : A a' 

rbp^p:% 


r b let x = s in t (Ax: \ a\ . e') e : A o 

Thp-wp: 


m h p 

r b_->|$ :* r 


rh(p:cr)^ 

L r J h 7 x 

p\> 7 v 


rbt^ 


rb P 

r b e : a -< e' : a' 


Figure 7.4: Non-deterministic elaboration of expressions 
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This rule inserts an abstraction based on the type scheme, leaving the term t 
unchanged. The variable is implicitly bound in the context, so it cannot be used 
in the source language. Similarly, the rules for _ markers and conversion 

[TJ b p :* t rhp^p:*T L r J h 7 ;D T ~ V 

rh_^p: f T rhp^p> 7 :% 

invent evidence out of thin air. This shows the non-determinism of the system. 

Applications are elaborated using the judgment for vectors of arguments, dis¬ 
cussed below. For example, if / : Bool — >• Int then the source term map / will be 
elaborated using the telescope (a A*, b A*,/ A ( a b), x A [a]) —>• [b] of map, 
inserting the two implicit arguments to produce map Bool Int /. Note that the 
vector may be empty, allowing constants (e.g. Nil) to take implicit arguments. 
Applications need not be saturated, except for applications of shared functions. 

Non-deterministic elaboration of vectors 

The judgment T h 6 S : A, defined in Figure 7.5, means that the vector 6 can 
be elaborated to <5 in the annotated telescope A. This inserts implicit arguments: 
for example, the source vector containing the single entry Bool can be elaborated 
in the telescope a A *. b a to the two-element vector * , Bool where the first 
component has been inserted. Usually-implicit arguments may also have been 
explicitly specified by the user: for example, the source vector {a = Z}, 3 can be 
elaborated in the telescope a :J *, b a to Z ,3. 

Non-deterministic elaboration of type schemes 

The judgment T h a a, also defined in Figure 7.5, means that the inch 
type scheme cr can be elaborated to a. This is entirely structural; the only 
interesting behaviour is when elaborating types. Elaborating the codomain of a 
type scheme always takes place with the domain variable bound explicitly, even if 
the quantification is implicit, since the variable is still in scope for the codomain. 
As an example, the type scheme for replicate 

Va::*.IIn::N—>-a—>• Vec a n 

can be elaborated to the evidence type scheme 

(a A n :g N, x A a) — > Vec a n. 
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(vector b can elaborate to 8 in telescope A ) 


Thb-^8: A 

r b p p :* 0 - T\-b^8: [p/x] A 

r b • • : • r b p, 6 -w p, 8 : x :f a, A 

rhp^p:% [rj b p :* K 

r b 6 -w (5 : [p/a] A r b 6 5 : [p/a] A 

r b (a = p}, b ^ p,8 : a:f k, A r b 5 5 p, 5 : a :f k, A 


Thff -w cr (scheme u can elaborate to a) 

r h t r : v * ri-K-wfc^* r, a / k h a ^ (T 

rhT -w t r b V(o:K).ff (a :? «) -4 a 


r b K W K : V * 

r, a ig k b (T cr 
T b V(a: k) —y a (a :/ k) —)• cr 

ThT^r: v * 
r, X !g T b (7 cr 
r b n(x:T). a (a; t) —>• cr 

r b o' a' 
rb(/4(j ^ 


r b T w T : v * 
r,i:^rbff -w a 
r b II(x:t) — > a -W (x t) —> cr 

r b T <p : v * 

r,c: e D yb(j o- 
r b r =>- CT (c :? <p) —> cr 

T b a o- 

(x cr') -» a 


Figure 7.5: Non-deterministic elaboration of vectors and type schemes 
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(scheme a is subsumed by a', converting e to e') 


| T b e : a -< d : a' 

Lrj b e : A L^J L r J h 7 T ~ V 

r b e : a -< e : a T \- e : t < e\> ^ \ v 

r » y '-e a o b y : -< e' : a 0 F, y A a' 0 \~ e e r : a 1 ^ e" : a[ 

r b e : (x : A <7 0 ) ->• a x -< Ay: A [a' 0 \ . e" : (y : A a' 0 ) -)• a[ 

[rj b 7 : D y ~ r r, b : J u b e (6 > 7 ) : [b > 7 /a] a ^ e' : a’ 

T b e : (a :J r) —>• cr -< A 6 : x u. e' : (b :J -u) —>■ a' 

Lrj bp r 

T b ep -< e : a T, a :f t b e : a -< e' : a' 

rbe:(a:fr) 4 ff^e':ff' r b e : a -< Aa: $ r. e' : (a :f r) ^ b 

Figure 7.6: Non-deterministic subsumption 

7.3.2 Subsumption 

Programs involving higher-rank types may require the elaborator to do more than 
insert implicit arguments in order to assign the right type. For example, if 

s::Va. Bool —> a 

y:: (Vfe.(Vc.c) b) -)■ Bool 

then the application y x should be well-typed. The elaborator must check that 
x has the scheme V b . (V c. c) —>• b, which is more specific than V a. Bool —> a 
thanks to the contravariance in the domain, as Bool is more specific than V c. c. 
The conversion rule for terms 

T b t e <7 T b e : a -< e' : a' 

T b t w e' : A a' 

invokes the subsumption judgment T b e : a -< e' : a' to verify that o' is more 
general than < 7 . This judgment, defined in Figure 7.6, constructs e! corresponding 
to e but with appropriate (implicit) abstractions and applications so that it has 
type scheme a' rather than a. 

In the example given above, e — x with scheme <7 = (a :( *,z : A Bool) —> a 
and cr' = ( b *, z : A ((c A *) —>• c)) —>• b. The variable b is bound in the context, 
so it can be substituted for a. Then both schemes are explicit ^-quantifications, 
so the contravariance rule applies and checks that (c *) —> c is below Bool. 
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In turn, this instantiates c with Bool and applies reflexivity. Having checked the 
domains, the contravariance rule checks the codomains, which are identical. The 
resulting evidence term is y (A b: y * .A z: ((c: v *) —>• c) .xb (z Bool)). 

Since subsumption involves inserting implicit A-abstractions, it is only avail¬ 
able for terms (at phase X ). It is not possible at a static phase T because there 
is no type-level A-abstraction. Instead, the conversion rule for types 

T b p p t |_rj b 7 : D t ~ v 

rhp-wp>7: 4 'n 

can only appeal to a proof of type equality. This restricts the utility of higher-rank 
definitions at the type level. 

7.3.3 Soundness of non-deterministic elaboration 

Obviously, the non-deterministic system should be sound in the sense that the 
resulting evidence expression is actually well-typed. 

Theorem 7.1 (Soundness of non-deterministic elaboration). 

(a) J/T b p ^ p a forty e {V,n,A}, then |TJ b p :* 

(b) IfT b a -w a then [TJ b [aj : v *. 

(c) //TbS^TA then [rj b 5 : [AJ. 

(d) IfT\~e:a-<e':a' and |_TJ be A then |_TJ b e' :A 

Proof. Straightforward structural induction on derivations. □ 

While this system provides a helpful starting point, it does not define an 
algorithm. The same syntax can be translated in many different ways depending 
on the placement of implicit applications and quantifications. For example, the 
inch term Xx.Xy.x y could be translated to Aa: v * . AbX* . Xx: (a —>• b) .Xy.a.xy 
or A b: w * . Xx : ((a : v *) —>• a —>• b). Xy : Bool. x Bool y or many other mutually- 
incompatible evidence terms, with no principal or canonical choice. Even if the 
type scheme is known, there are many unspecified choices. 

To describe the deterministic algorithm, I must first extend the type system 
to support metavariables, which will stand for the unknown types and proof 
obligations (constraints) that arise during elaboration. 
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7.4 Metavariables and information increase 

Just as in the unification and type inference algorithms of Part I, a metacontext 
0 contains declarations of metavariables to represent unknowns that arise during 
elaboration. This includes types, represented by metavariables a and /3, and 
coercion proofs £. Each metavariable has a telescope A of parameters, and a 
kind k that may depend on A. 

Metacontexts may also bind variables. Like the annotated contexts of Sec¬ 
tion 7.1, these record whether the binding is implicit or explicit. Source language 
programs may refer only to explicitly bound variables. 

The grammar of metacontexts is given by 

0 ::= metacontext 

| • empty 

0, a [A] k unknown metavariable 

0, a [A] = p k defined metavariable 
0, a :f a explicitly-bound variable 

0, a :f t implicitly-bound variable 

I will use 5 for a metacontext that contains only metavariables; the telescopes T, 
A are metacontexts that contain only variables. 

As in previous chapters, metacontexts are ordered by dependency. Figure 7.7 
gives the rules for a valid metacontext, generalising the judgment T b ctx defined 
in Figure 6.5 (page 118). This ensures that metavariables are defined uniquely 
and that their types are well-kinded. The sanity condition (Lemma 6.9, page 127) 
continues to hold: if 0 b mctx then E b sig. The typing rules in the previous 
chapter are generalised by replacing T with 0 and T b ctx with 0 b mctx. 

The syntax of evidence expressions is extended with a new form a ^ for 
metavariable occurrences, where 8 is a vector in A. I add a typing rule for 
metavariables to the rules in Figure 6.6 (page 119): 

0 9a[A]: $ /t T b <5 : A $ ^ 

T b cJ 5] :* [S/A] k 


Metasubstitutions 

A metasubstitution 0 : 0o C 0 t gives values for metavariables in the metacontext 
0 O in terms of the metacontext 0i. Since metavariables have parameters, each 
component of a metasubstitution takes the form A.p / a where A is the telescope 
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Q h mctx 

Ehsig a#© 0,Ah k : v * a#© 0,Ah p k 

■ h mctx 0, a [A] k F mctx 0, a [A] — p ^ n F mctx 

a#0 0 F [crj : v * $ ^ □ a#0 0 F r : v * $ ^ □ 

0, a ig a - F mctx 0, a :f r F mctx 

c#0 0h^: v * 

0, c </? F mctx 


Figure 7.7: Validity of metacontexts 


9 : 0p C0i| 

9 : 0 O g ©1 0i,0Ahp 9k 
■ : ■ □ S (i 9,A.p/a ) : 0 O , a [A] k E 0 : 

0:0 o C©i 0i, 0A hp = 0p' :* 0 k 0:0 o C0i 

(0, A.p / a) : 0 O , a[A]=/)': $ KC6i 0 : 0o, a a C ©i, a :f 9 a,E 

9 : 0 O E ©i 

0 : 0 O , a :f r C ©i, a :f 0 r, 8 


Figure 7.8: Metasubstitutions 
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for a, and binds variables in p. Valid metasubstitutions are defined in Figure 7.8. 
The rules ensure that metasubstitutions preserve the structure of variables in the 
metacontexts, as in Subsection 2.1.2 (page 14). 

Metasubstitutions act on syntax by the structural closure of 

6 (->• [<S/A] t where 6 contains A.r / a. 

The identity metasubstitution t is defined in the usual way, replacing each 
metavariable with itself. I write 0o E ©i where the information increase is by 
the identity metasubstitution. 

Lemma 7.2 (Metasubstitution). If 6 : 0 O Q ©i and 0 O F J, then ©i h 9 J. 
Proof. By induction on derivations. □ 

7.5 Deterministic elaboration 

The deterministic elaboration algorithm is built from the non-deterministic re¬ 
lation by attaching input and output metavariable contexts, allowing missing 
information to be replaced with metavariables. It is defined in a bidirectional 
style, based on the following judgments defined in Figures 7.9 and 7.10: 

• ©o p -w sch p : cr H ©i, meaning that p elaborates at phase T to p with 
assigned type scheme a; 

• ©o F* p p : t H ©i, meaning that p elaborates at phase T to p with 
inferred type r; and 

• ©o F w p : cr p H ©i, meaning that elaborating p with the type scheme a 
at phase T produces the evidence term p. 

The following auxiliary judgments are defined in Figures 7.11-7.13: 

• ©o F (T a H ©i, meaning that the type scheme a elaborates to <r; 

• ©o F 41 (p : cr) 6 p' : t H ©i, meaning that elaborating the spine of 

arguments 6 applied to the elaborated head p : a results in p' : r; 

• ©o F 6 : A ^ <5 H ©i, meaning that elaborating the components of the 
vector 6 in the telescope A results in 6 ; and 

• ©o F e : a -< a' e' H ©i, meaning that the scheme a is subsumed by a' 
and if e has scheme a then e' is the corresponding term with scheme a'. 
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Finally, the judgment 0 o hr~«^ 7 H 0i, means that r and v are unified, 
witnessed by the coercion 7 . This is an invocation of the constraint solver, which 
I do not specify in detail. I discuss this further in Subsection 7.5.1. 

For all these judgments, the parameters before the arrow are inputs, and 
they determine the outputs (which appear after the arrow). In general, informa¬ 
tion flows clockwise through each inference rule, with the inputs to the conclusion 
determining the inputs to the first premise, whose outputs determine the inputs to 
the next premise, and so forth, until the outputs from all the premises determine 
the outputs of the conclusion. In this way, the rules yield an algorithm. 

The distinction between scheme assignment 0 O h* p -w sch p : <7 H 0 1 and type 
inference 0 O ^ p ^ p : t H 0i is that schemes are not inferred, only looked up 
in the context or explicitly annotated by the user. A single application rule allows 
an expression with a scheme to have its type inferred, by checking the vector of 
arguments (which may be empty) and completing the scheme to produce a type. 
Expressions with inferred types are embedded in those with assigned schemes 
because the head of an application may be a A-expression (i.e. in a /3-redex) or 
other expression that does not have an assigned scheme. 

Example of elaboration 

Recall the example inch term Xx.Xy.x y. This is elaborated by generating fresh 
metavariables for the domain types, so under the abstractions the context will be 
a [• ] : v *, x ;A a,/3[- ] : v *, y /?. The application x y is elaborated by looking 
up the type a of a: in the context, and checking the vector y against it. Since 
the type does not start with a quantifier, fresh metavariables a 0 and aq for the 
domain and codomain are created, and the constraint a ~ (a 0 —> aq) passed 
to the constraint solver. Then y is checked at type o 0 , but looking up its type 
gives j3 and the subsumption judgment generates another constraint, /3 ~ ot 0 . 
Assuming no constraint solving, the resulting evidence term is 

Xx:a. Xy:(3. (x>C) (y>C) 


in the context 

a [• ] ;V 1’ I ;V *, "o [• ] : V *, op [• ] : V *, C [■ ] : D a ~ («o -A «i), C [• ] : D P ~ «o- 
In practice, the unifier will solve the constraints to give the context 
a o I ] : V *, [• ] : V *, a [• ] = a 0 aq : V *, P [• ] = «o : V * 
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(checking p at scheme a and phase 'I' delivers p) 


0 O b* p : a p H 0! 

0 O , a :f k b A t : a e H 0i, a :f n, S 
0 O b A t : (a :f k) — »• a A a:®n. e H ©i, (a /c) /' S 


0 O , x cr' b A t : cr e H 0 i, x :f cr', 5 
0 O b A Ax . t : (x ig cr') —>• cr (Ax: $ |_cr'J . e) H ©i, (x cr') /' S 

©o b A s ~^ sch e : cr H ©i ©i, x : A cr b A t : cr' e' H 0 2 , x : A cr, S 

©o b A (letx = sint) : cr' (Ax: \cr\ . e') e H © 2,5 


©o b A t ~A ch e : a H ©! 

©i h e : cr -< cr' -w e' H © 2 

©oh' 3/ _:r^/3H0 o ,/3[- ] :* r © 0 b A t : a' -w e' H © 2 


©o b T p p : r H ©i ©i h r ~ v 

©o b T p : v p > 7 H 0 2 


7 H ©2 


Figure 7.9: Type-checking elaboration 
with reflexive proofs of the coercion metavariables, and the evidence term 
Ax:(o:o -* a 1 ).\y:a 0 .(x>(a 0 - 7 - 07)) (y>{a 0 )). 

Parameterisation 

The operation A /* 5 parameterises the metavariables S over a telescope A: 

A/*- ^ • 

A (a [T] :* k, S) ^ a [A, T] :* k, A S 

This allows a telescope of variables to be taken out of scope during elaboration, 
such that any metavariables introduced retain the appropriate parameters: if 
©, A, S b mctx then 0, A / S h mctx. It permutes existential quantifiers 
from right to left past universal quantifiers, the ‘raising’ of Miller (1992). 

This definition and its uses involve a slight abuse of notation, as formally 
all occurrences of metavariables from H should be replaced with occurrences in 
which the parameters are prefixed by the identity substitution: for example, 
a :g k, fd [■ ] : v k b j3^ : v k but /3 [a : v k] ? k, a k b : v k. In practice, I will 
elide the necessary weakenings. 


159 






Q 0 b'*' p -w sch p \ a -\ Q x | (p elaborates to p with assigned scheme a) 

Q 0 3x:f a $ ^ E 9 H <7 $ ^ 

0o b (T a H 0i 

0! b* p : a ** p H 02 0 O h f p -w p : r H 01 

0o b* (p: a) -w sch p : o' H 0 2 0 O b* p -w sch p : r H 0 X 

(p elaborates to p with inferred type rj 

E 9 / [A] k <F M- 'F 
0 O h 6 : A // $ -^ <5 H 0 t 

0 O b v k : * -w k H 0i 0i, a k h v T : * r H 02, a k,E 

0 O b v V(a: k) —>■ t (a-y k) —>• r : * H 0 2 , (a : v k) /' 5 

0 O b v T : * t H 0i 0i, j: :f r h v i) : v H 0 2 , x t, 5 

0 O b v 11 (x: t) —>■ l) -w (x: n T) —>• v : * H 0 2 , (x : n r) 5 

0o b v T : * t H 0i 0i b v v : * v H 0 2 


00 b' 


->• v : * H 0 2 

0o, a [’ ] : V *, 

x : A a b A t ~ 

► e : t H 0i, x : A ce, S 

0 O b A Ax. 

t (Ax:o:. e) 

: (a ->• t) H 0i,5 

w sch e : a H 0i 

0i,x 

^ cr b A t e' : t H 0 2 , 

0 O b A (let x = 

: sint) (Ax 

: \cr\ • e') e : r H 0 2 , 5 


©o ^_^^:oH0 Ol a[-] : V *,/?[•] a 


Figure 7.10: Type-reconstructing elaboration 



0 O b* p ^ sch p : a H 0i 
0i b* (p : a) 6 p' : T H 0 2 
0 O b^ p 6 -w p' : r H 0 2 
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(scheme cr elaborates to a) 


e 0 htr^Hei 


0 O h v T : * ^ r H @1 

©0 F T 1 I 0i 


0 O F v K : * -W k H 0! 0i, a ■(, k \~ u a ~\ 0i, a k, 5 



0 O F V(a: k). a ~ 

•* (a /c) —> a H ©i, (a 


00 

h v K : w k H 0! 

0i, a ig /c F c 

cr H ©!, a ig /c, 5 


0 O F V(a: k) —> cr 

(a ig /c) —>■ cr H ©!, ( 

a : v /c) H 

©0 

F v t : * r H 0i 

©!, x :® r F a -w 

a H 0i, x t, 5 


0 O F n(x:T) ->■ a 

(x t) — »■ cr H 0i, ( 

> :"t)/3 

00 

F v t : r H 0i 

0i, i ij r F a ^ 

a H 0i, x t, 5 


0 O F n(x:T). a ~ 

* (x :f r)4H 0i, (x 

;: n 

Bo 

F v t:^^H0! 

0i, c^Fd'w 

cr H ©!, c !g <p, E 


©o F t =>- a Ifi ifi) — > <j H 0i, (c : D ip) /' S 


0o h (J* ^ a ( H 0i 0i h a a - H 0i 

0 O I - —y o" (x o’*') —y a ~\ 0 i 


Figure 7.11: Elaboration of type schemes 
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(applying p : a to 6 results in p' : t) 


Qq b* (p : a) 6 : T H ©7] 

0 O b*/ /4> p' : a' w p' H 0 X 

0i h* (pp' : [p'f a\ a) 6 p" : r H 0 2 

0 b 41 (p : cr) • -w p : |_cr_| H 0 0 O b 41 (p : (a cr') —> cr) (p', 5) p" : r H 0 2 

0 O b*^* p'l^p'H©! 

0i b^ (p p' : [p7a] <j) 6 p" : t H 0 2 
0 O b 4 ' (p : (a :f /c) ->■ cr) ({o= p'}, S) ^ p" : r H 0 2 

0 o ,o; [• ] /c b^ (po : [a/a] cr) 6 -w p' : r H ©i 

0 O b 4 " (p : (a :f rc) —> cr) 6 p ; : t H 0i 

©o, a [■ ] : V *,P [■ } : V * b v ~ (o -)• 0) 7 H 0i 

©ib 4 ' (p > 7 : o —>• / 3 ) 6 p' : t H 0 2 
©o b^ (p : u) 6 -w p' : r H 0 2 


©o b 6 : A -w 5 H 0i 


0b ■ ; • -w • H0 


(vector 6 in telescope A elaborates to 6) 
0 O b 4 p : a p H 0i 

©i b 6 : [p/a]A^H0 2 
©o b p,6 : a :f a, A p, 5 H 0 2 


0 o b $ p: ft wpH0i 

0i b 6 : [p/a] A — 5 H 0 2 0 O , o [• ] :* k b 6 : [a/a] A^HQi 

@o b {a = p}, 5 : a:f K,A^p,H0 2 0 O b 5 : a ;f k, A -w o, 5 H ©i 


Figure 7.12: Elaboration of spines and vectors 
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(a is subsumed by a', converting e to e!) 


Q 0 F e : a -< a' e' j Qi | 

0 h e L^J 

0he:cr-<cr'weH0i 


0 ol“T~v~^ 7 H 0 i 

0ol _ e:r-<V'^e[>7H0i 


0 O , y (Jq b y : a' 0 -< a 0 e' H ©i 
0 i b e e' : <7\ -< a[ e" H 0 2 , y a' 0 , S 
0 O h e : (x <t 0 ) -)• <7 i -< (y cr' 0 ) a[^ Xy: [a' 0 J . e" H 0 2 , S 


0 oI _ 'u~t~^ 7 H 0 i 

0i, b :J -u h e (b > 7 ) : [6 > 7 /a] a -< a' e' H 0 2 , b v,E 

0 O F e : (a t) —)• cr -< (6 :J u) —>• cr' Ab: r v. e' H 0 2 , ( b : r v) /* E 

0 O , a :f k F e : a -< a' e' H © 1 , a :f k, S 
0 O F e : a -< (a :f k) —>■ cd Aa: $ ac . e' H ©i, (a «) 2 

0 O , ol [• ] k F e a; : [a/a] cr -< a' e' H ©i 

©o hsf: (a :f k)—* a -< a' e' H ©i 


Figure 7.13: Subsumption 


7.5.1 Unification 

The unification judgment 0 o hr~r^ 7 H 0 i means that unifying r with v 
in metacontext 0 O produces the proof 7 in metacontext ©i. Conceptually, it is 
defined using the single rule 


0o, C[- ] r ~ v 0i 

0 o I-t~i;^(H 0 i 

where a new proof obligation / (a metavariable at phase □, also known as a goal) 
is added to the metacontext and a backward chaining proof search procedure is 
invoked to take as many steps 0 -» 0 ' as possible, solving or simplifying goals. 

I will not define the proof search algorithm (the -» relation) fully, as my focus 
is on elaboration rather than constraint-solving, but a few comments on the steps 
it would take are in order. 

The basic inference rules for backward chaining are the coercion constructors. 
For example, if the metacontext includes a goal of type T\ r v l ~ t 2 t u 2 , then 
backward chaining on congruence of application would turn this into subgoals 
with types T\ ~ r 2 and v\ ~ u 2 . The coercion constructor allows a witness to 
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the original goal to be built from the subgoal metavariables. In this example, the 
metacontext 

©, C [A] : D Ti V! ~ t 2 v 2 

can be replaced with 

0, Co [A] : D fj ~ r 2 , Ci [A] : D v x ~ v 2 , C [A] := D conga T Co Ci- 

Similarly, other congruence rules can be used to decompose rigid-rigid constraints, 
the step p constructor can be used to reduce (compute) expressions and coherence 
can be used to remove coercions from equational goals. 

Flex-flex or flex-rigid constraints (between two metavariables or a metavari¬ 
able and a rigid term) can be solved by inversion and intersection, along the lines 
of the higher-order unification algorithm discussed in Section 4.2 (page 67). 

The local parameter telescope of a goal contains the hypotheses available for 
proving that goal, which may allow it to be solved or simplified via backward 
chaining. For example, the goal f[c : D b ~ a] : D a ~ b can be solved by ( [c : D 
b ~ a] := D sym c. Introducing a hypothesis uses A-abstraction for coercions. 

Since the integers form an abelian group, constraint solving for linear integer 
constraints can follow the approach taken in Chapter 3. 

Assuming that the proof search algorithm is sound (i.e. all steps are identity 
metasubstitutions), its embedding into elaboration is sound: 

Lemma 7.3 (Soundness of unification). Suppose that for all 0 and 0', 0 -» 0' 
implies © □ ©'. If 0 O F r ~ v 7 H ©i then 0 O E 0 X and ©i h 7 : D r ~ v. 

Proof. By transitivity of metasubstitution and the typing rule for metavariables. 

□ 


7.5.2 Soundness of elaboration 

The elaboration algorithm is related back to the non-deterministic specification 
by the following theorem, which states that the algorithm produces one possible 
elaboration of the input term. 

Theorem 7.4 (Soundness of elaboration). Suppose 4/ e {V, II, X}- 

(a) If 0 O b' 1 ' p -w sch p : a ~\Q 1 then 0 O E 0 : and ©i b p p a. 

(b) If 0 O b^ p -w p : r H ©i then 0 O C 0 : and ©i b p p r. 

(c) If ©o b^ p : a p H ©i then 0 O C © x and ©1 b p p a. 
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(d) //0 O I- O' cr H 0i then 0 O E 0i and ©jhff -w a. 

(e) If 0 O h p p a and 0 O h* (p : a) 6 p' \ r H ©i f/jen 0 O E ©i and 

0 i b p6 r. 

(7; If 0 O h 5 : A w <5 H 0i then 0 O E ©i orad 0i h 6 5 : A. 

(g) If 0 O I- e : a -< a' e' H ©i ^/iera 0 O E ©i and ©i h e : cr -< e' : a 1 . 

Proof By induction on derivations, using Lemma 7.3 for unification. □ 


7.6 Elaboration for case analysis 

The system I have presented so far lacks case analysis, which is rather important in 
practice. Therefore, I will now present the elaboration rules for case expressions, 
extending the previous non-deterministic and deterministic systems. 

I will consider only flat (non-nested) pattern matches; nested pattern match¬ 
ing is a well-studied topic (Augustsson, 1985) that can be presented via elabora¬ 
tion, but would complicate the presentation further. 

Moreover, I will continue to assume that case expressions are covering. It 
is easy to amend the elaboration rules for case expressions to insert missing 
branches that generate an appropriate runtime error. True coverage checking 
is less straightforward, because for each omitted data constructor the constraint 
solver must establish that the constraints it introduces are unsolvable. Goguen 
et al. (2006) suggest extending the language of patterns with ‘refutations’, which 
allow the programmer to indicate arguments that are uninhabited. 

The grammar of expressions p (and correspondingly terms t and types r) is 
extended by case and dcase expressions: 

p ::= (d)case pof brj | ••• 
br ::= K vs —> p 
vs ::= • | x, vs | {a=b},v s 

Each branch br in the inch source language matches a single data constructor K 
and binds variables vs, some of which may be implicit. The syntax {a = b} means 
that the implicitly bound variable a in the telescope of the data constructor should 
be brought into scope with name b, that is, the right-hand side of the equation 
is the binding occurrence. 
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(p can elaborate to p with scheme a at phase 4 /) 


rhp^ p: $ D Vi * rhr : v * 

r b br 0 bro :' p D v\' 1 ► f ... r b br n frr n Dr^* ► r 
r b case pof br 0 ... br n case pof br 0 ... br n r 

r bp^ £ : n//l Dtb* r br : v * 

rbbr 0 w br 0 (e : Dig®) ► r ... T b br„ br n (e : D <.y*) ► r 

r b dcase pof br 0 ... br n dcaseeof br 0 ... hr n r 


r b br br D -0 ► r | (4>r can elaborate to br at phase 4/ ) 

E 9 K :* (gTT^S‘ 1 A ) D a, ® $ 

vs : [Vijaj 1 ]A -» A 7 

r,A'bpy»/):*T _ 

r b (Kvs —» p) (K |_A'J -> p) Dv^ 1 ► r 

r bbr wfrr :* (£ : DVQ ► ~rj (d>r can elaborate to br at phase 4/ ) 

Bb K A ) -> D<yi $4n//$ 

vs : ['Uj/a/jA/n -» A 7 
A" = A',c:°£~(K^A') 

r, a" bp^p^r _ 

r b (Kvs —>■ p) (K [A"J —>■ p) : 9 (e : D^ 1 ) ► r 


A 7 


vs : [x/y]A -» A 7 
x,vs : y:f a, A -» x :f a, A 7 


vs : 



vs : [ 6 /a] A -» A 7 $ 7 ^ □ 
{a = b}, vs : a :f k,A -» b :f k, A 7 


Figure 7.14: Non-deterministic elaboration of case expressions 
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7.6.1 Extending the non-deterministic system 

Figure 7.14 gives the new non-deterministic elaboration rules (extending those 
in Figure 7.4) for non-dependent and dependent case expressions. In each rule, 
the scrutinee is elaborated to give an expression of type D|fp, then each of the 
branches is elaborated and must deliver a common type t, the type of the whole 
expression, which must not depend on variables in any of the branches. For the 
dependent case, the scrutinee is elaborated at phase II / 4/ (rather than 4>) to 
ensure that it can appear in types and at runtime (if necessary). 

The judgment T b br br :' T ' D ty * ► r means that the case branch br can 
be elaborated to br, where the scrutinee has type and the result has type 

t. Branches must be of the form K vs —>• p where K is a constructor of D and 
is accessible at the current phase. The implicit and explicit variable bindings vs 
are elaborated in the constructor’s telescope A to produce another telescope A' 
that is in scope when the result of the branch is elaborated. For GADT matches, 
this telescope will include the equational constraints encoded by the GADT. 

Similarly, the judgment T h br ^ fcr :* (e : D^ j ► t means that the 
dependent case branch br can be elaborated to br, under the assumption that the 
scrutinee is equal to e. 

The judgment vs : A -» A' means that matching the source language 
bindings vs against the annotated telescope A of a data constructor results in the 
annotated telescope A'. This gives the telescope needed to elaborate the result 
of a case branch, using the binding names from vs but obtaining their types from 
A. Implicit bindings are introduced silently, or the user can explicitly bind a 
name that would usually be implicitly bound. This resembles the judgment for 
elaborating vectors in Figure 7.5, but for patterns rather than general expressions. 

As an example, consider the following definition of append via case analysis: 

append zs ys = case zs of 

Nil Nil 

Cons {m = m'} x xs —>• Cons x (append xs ys) 

To check the Cons branch, recall that the type scheme for Cons (after the GADT 
translation), is (A) —>• Vec a b where 

A = a -Y *, b A N, m A FJ, x a, xs Vec am,c (b ~ Sue m). 

The bindings {m= m!},x,xs are successfully matched against the telescope A, 
renaming m to m! and introducing a, b and c implicitly. The branch result 
Cons x (append xs ys) is then elaborated under the renamed telescope of bindings. 
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Soundness of non-deterministic elaboration (Theorem 7.1) must be extended 
with the following additional cases: 

Lemma 7.5 (Soundness of non-deterministic elaboration for case analysis). 

(a) If T b br -w br Dlf|t ► r then T h br D v i ' 1 ► r. 

(b) //Thbr-w br (e : D v i ' 1 ) ► r then T b br (e : Dt^*) ► r. 

Proof. By structural induction, mutually with Theorem 7.1. □ 

7.6.2 Extending the deterministic system 

Extension of the deterministic elaboration system is mostly routine, following the 
non-deterministic system. Figure 7.15 gives the additional elaboration rules for 
case expressions (extending the rules in Figures 7.10 and 7.9). As in the non- 
deterministic system, auxiliary judgments 0 O h* br : v ► r br H 0i and 
0 O h® br : (e : v) ► r br H 0i describe elaboration for individual branches. 
I write a list of semicolon-separated elaboration judgments to mean that the 
metacontexts are threaded through from one to another. 

In the deterministic system, case expressions are checked, rather than having 
a type inferred. Inference is dealt with by generating a fresh metavariable 3 and 
checking that the expression has type f3. It is not immediately apparent how 
the datatype D is to be determined: it might be obvious from the type v of the 
scrutinee, but it might not (if a constraint must be solved to show that v is an 
algebraic datatype). Alternatively, the types of the data constructors from the 
branches can be consulted, provided the case expression is non-empty. 

Soundness of elaboration (Theorem 7.4) is extended with the following: 

Lemma 7.6 (Soundness of elaboration for case expressions). 

(a) If @o h* br : DSjgt ► r 6r H 0 X then 0 X h br br :* > t and 

0o E 0i. 

(b) If 0 O h* br : (e : D^) ► r br H 0! then 0 X b br br :* (e : Duj ! ) ► r 
and 0o E 0i- 

Proof By structural induction on derivations, mutually with Theorem 7.4. □ 
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(p elaborates to p with inferred type r ) 


e 0 b* p -w p : r H e, 

©o, P [• ] : v * I-’ 1 ' (d)case pof br 0 ... br n : /3 -w p -\ 0 X 
0 O b^ (d)case pof br 0 ... br n 1 


0 p b* p : a p -| 0 i (checking p at scheme a and phase 'I' delivers p) 


0 O b® p p : v H 0i 0i, a* [• ] : v /c* * b v ~ D atff -w 7 H 0 2 

0 2 b® br 0 : DSi* ► r 6 r 0 ; ...; br n : Doj’ ► t br n H 0 3 

0 O b^ case pof br 0 ... br n : r case p > 7 of br 0 ... 6 r n H 0 3 

0 O b 11 ^ 4 ' p £ : v H 0 ! 0 i, a,i [• ] : v /c/ bt;~ D 07* -w 7 H 0 2 

0 2 b^ br 0 : (£>7 : Doj 1 ) ► r br 0 ; ...; br n : (£>7 : D07*) ► r &r n H 0 3 
0 O b^ dcase pof br 0 ... br n : r dcasee > 7of br 0 ... 6r n H 0 3 


0 O b^ br : v ► r br H 0 ij f case branch br elaborates to br) 

E9K: $ (o,- k/, A) -)• Dai* $-4^ 

vs : [vj/a/]A -» A 7 
0 O , A' b^pir^pH^A'S 
0 O b^ Kvs — > p : D<&/' ► r ^ KA ^/H 0,. A /' S 


0 O b* br : (e : v) ► r br H ©J (dependent case branch br elaborates to br) 


E 9 K :* (oi -f Ki\ A) D||* 
vs : [ Pj/oj * ] A H II -» A' 

A" = A 7 , c f £ ~ Kt^A' 

© 0 ,A" b* p:r^/?H0 1 ,A",S 
0 O b^ K vs —* p : (£ : D|j||) ►r^KA'^pH ©i, A' /*% 


Figure 7.15: Elaboration of case expressions 
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7.6.3 Example of elaborating a function definition 

Recall the replicate example from previous chapters: 

replicate :: Va :: * . n n :: N —>• a —>• Vec a n 

replicate n x = dcase n of 
Zero -4 Nil 

Sue m -4 Cons x (replicate m x) 

How will this be elaborated, as a shared function? Elaborating the type scheme 
produces (A) -4 Vec a n where A = a :?*, n N, x a, so the body should be 
elaborated at phase n in the context replicate [A] : n Vec a n, A. Thus recursive 
calls to replicate can be made at phase n, and its arguments are in scope. 

To elaborate the body, the dcase expression must be checked at type Vec a n. 
The scrutinee n is inferred to have type N. It must then be checked that each of 
the branches accepts this scrutinee and produces a result of type Vec a n. 

In the Zero branch, the constructor telescope is empty so the only variable 
brought into scope is an implicit proof c n ~ Zero. The result Nil must then 
be elaborated at type Vec a n under this hypothesis. Since its type scheme is 

( a *,n:( N,c:°n~ Zero) -4 Vec a n 

the rule for elaborating a term applied to a spine of arguments (empty, in this 
case) generates metavariables a, /3, ( for the implicit arguments, so Nil elaborates 
to Nil a (3 ( of inferred type Vec a (3 with the proof obligation £ : D /3 ~ Zero in 
the context. Subsumption allows this term to be checked at type Vec a n, adding 
another proof obligation £' : D Vec a fJ ^ Vec a n and resulting in the term 
Nil a /3 C > £'. It should not be difficult for the unifier to solve a := a and [3 n, 
so (' is reflexive. Then (: a Zero can be solved by c. The final branch is: 

Zero (c : D n ~ Zero) —> Nil a n c> (Vec a n) 

The coercion by reflexivity can be removed. Other solutions to the constraints are 
possible, but they affect only the coercions, which are operationally irrelevant. 

In the Sue branch, the constructor has telescope y :(■- N, and matching the 
source-level bindings against it gives m : (y :£■ N)/n -» m N so the match 
brings into scope m and a proof c n ~ Sue m. Insertion of implicit arguments 
proceeds similarly to the Nil case. The scheme A for the recursive call to replicate 
is supplied by the context, and is used to check its vector of arguments a, m,x. 
The final result of elaborating the branch (omitting coercions) is: 

Sue (m : n N, c : D n ~ Sue m) -4 Cons a n m x (replicate (a, m, x)) c 
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7.7 Discussion 


In this chapter, I have presented an algorithm for elaborating the inch source 
language of Chapter 5 to the evidence language of Chapter 6. While it does not 
cover every feature available in Haskell, it does demonstrate the way in which an 
elaborator can be built up to cover a large source language, retaining confidence 
in the system through translation of source programs into an intermediate rep¬ 
resentation. The elaborator supports dependent n-types with type-refining case 
analysis, higher-rank types and GADTs, though the exact capabilities will depend 
on the underlying unification algorithm. I have also presented an approach to im¬ 
plicit argument synthesis that generalises the current Haskell policy of ‘invisible 
types, visible terms’ to allow for explicit type application and implicit n-types. 

7.7.1 Generalisation 

Chapter 2 demonstrated that generalisation of polymorphic let-definitions can be 
performed through ‘skimming off’ metavariables from the context after inferring 
the type of the dehniens. Chapter 3 extended this to deal with abelian group 
unification. However, in the more complicated situation of inch elaboration, 
generalisation becomes yet more problematic. The presence of local constraints 
and parameterised metavariables means there is no reasonable way to decide 
which metavariables to generalise: attempting to generalise over parameterised 
metavariables leads to non-principal solutions. 

For example, suppose the expression being generalised has type a —> a, and 
the context suffix is a [■ ] : v *,£[c : D f3 ~ Bool] : D a ~ Bool. In this case, the 
type of £ does not depend on its parameters, so we could discard the hypothesis 
c and generalise to produce a result of type (a *) — > (z a ~ Bool) —> a —> a, 
i.e. Bool —> Bool up to isomorphism. However, if we refrain from generalising and 
later discover that a ~ /3 then the result has type a —> a for a an unconstrained 
metavariable. The order of constraint solving is now crucial, different solutions 
may be found as a result of slight variations in the program, and in general 
elaboration becomes fragile. 

What hope, then, for generalisation? In inch , I follow the advice of Vytiniotis 
et al. (2010) that local ‘let should not be generalised’. 1 This strategy has the ad¬ 
vantage of simplicity, but other choices (some with a more heuristic character) are 
available. One might choose to generalise whenever a let-expression did not give 

1 Top level let-bindings can be generalised, because parameterised metavariables can either 
be solved or reported as errors. 
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rise to parameterised metavariables at all, perhaps because no local constraints 
were introduced by case analysis of GADTs or subexpressions with higher-rank 
types, or because all the constraints introduced were solved by unification on the 
fly. This has the advantage of allowing generalisation in common cases, but it 
may be difficult for programmers to predict whether generalisation will take place 
without knowing the details of the inference algorithm. 

7.7.2 Related and future work 

The non-deterministic elaboration system is reminiscent of the approach taken in 
the Definition of Standard ML (Milner et al., 1997), which specifies elaboration 
via a syntax-directed inductive relation, but leaves matters such as the use of 
metavariables in type inference to implementations. Such a declarative specifi¬ 
cation can be turned into a logic program via mode assignment (Berghofer and 
Nipkow, 2002), with the underlying constraints solved by first-order unification. 
In the setting of this chapter, however, constraints are more complex and the 
non-deterministic system is not so easily operationalised. 

Brady (2013) describes elaboration for Idris in terms of imperative tactics, 
taking inspiration from the work of McBride (1999) on the Oleg system. 

A full specification of unification in such a rich setting is complex, and I have 
only outlined the way it fits into the elaboration framework. The careful manage¬ 
ment of variable scope means that unification could be specified similarly to the 
Miller pattern unification algorithm of Chapter 4. The algorithm used by GHC, 
described by Vytiniotis et al. (2011), is very powerful but not straightforward to 
understand or implement. Further work in this area is desirable. 

I have outlined the treatment of higher-rank types, but have not discussed the 
role of bidirectional type inference in detail. Dunheld and Krishnaswami (2013) 
give an excellent account of a sound and complete typechecking algorithm for 
higher-rank polymorphism, in a similar spirit. 

Soundness of the elaboration algorithm with respect to the non-deterministic 
specification is easy to show, and termination 2 follows from its structurally recur¬ 
sive definition, but it would be valuable to prove further properties. In particular, 
Luther (2003) discusses the coherence property, which requires that all possible 
(non-deterministic) elaborations of a term should be behaviourally equivalent. 
This formalises the intuition that elaboration should fill in details for which there 
is only one sensible choice. 

termination in the sense of reduction to constraint solving, that is; termination of the 
constraint solver is another matter. 
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Chapter 8 
Applications 


In this chapter, the hard work of the previous chapters finally pays off. Having 
introduced the inch language and explained how to elaborate it into the evidence 
language, I now give examples of using it to write programs. I start with some 
familiar operations on vectors (8.1), before implementing merge sort (8.2) and left¬ 
leaning red-black tree insertion and deletion (8.3). I demonstrate an approach to 
checking the time complexity of function definitions (8.4). Finally, I show how 
to implement units of measure based on numeric constraints (8.5), in contrast to 
the built-in support for abelian groups described in Chapter 3. 

The inch preprocessor 

The examples in this chapter have been checked with a prototype implementation 
of inch 1 . The prototype consists of a preprocessor that typechecks a source file 
and converts it into type-correct GHC Haskell, erasing type dependencies. This 
means that certain features cannot be supported. For example, large eliminations 
(where types depend on shared terms) are impossible to implement. 

The prototype implementation differs from the language laid out in the previ¬ 
ous chapters in a number of respects. In particular, it retains a strong distinction 
between the term, type and kind levels, which limits its flexibility compared to 
the final design. The kind system consists only of *, Z and higher kinds; other 
promoted datatypes and kind polymorphism are not implemented. 

The language of shared expressions, that may occur in terms and in types, 
is heavily restricted: only integers and arithmetic operations are available. Sim¬ 
ilarly, type equality constraints may involve only integers, and GADTs may use 
only integer indices. The kind N is represented by Z with an inequality constraint. 


L http://hackage.haskell.org/package/inch, https://github.com/adamgundry/inch 



The flexible approach to implicit and explicit arguments based on type schemes, 
described in Section 7.1 (page 145), is not implemented. Rather, V-quantifiers 
are always implicit and Il-quantifiers are always explicit, even though they are 
written with a dot (so II (m :: N). r means II (m :: N) —>• t). 

Terms that he in the shared fragment must be marked with braces. This 
includes applications of II-quantified functions and the patterns that define them. 
For example, if /:: II (n:: N). Vec a n then / {x + 2} :: Vec a (x + 2). Otherwise, 
the syntax is broadly that of Haskell extended with kind signatures, scoped type 
variables, GADTs and higher-rank types. One minor extension is that multiple 
variables may share a kind signature: for example, V (m n :: N). t is legal. 

Type inference is implemented along the lines of elaboration as described in 
Chapter 7, although instead of generating evidence terms, dependency-erased 
Haskell programs are produced. Constraint solving is based on the abelian group 
unification algorithm in Chapter 3, extended to the ring Z. Any remaining purely 
numeric constraints are checked using a decision procedure for Presburger arith¬ 
metic (Diatchki, 2011). This works well for linear constraints, but means that 
support for constraints involving multiplication is more limited. 

Kind inference is not performed, so kinds must be annotated explicitly (oth¬ 
erwise they default to *). This means that variables will usually be explicitly 
quantified. In a more complete implementation, this would not be necessary. 

Newtypes are not supported; where they are used in examples, they have been 
manually translated to the corresponding single-constructor data type behind the 
scenes. Support for typeclasses is extremely limited, and they will generally not 
be used in the examples. 

Despite these restrictions, it is still possible to implement useful examples. 
Where relevant, I will point out opportunities to improve the examples given a 
full-scale implementation of the inch system. 


8.1 Vectors 

Recall the definition of vectors as an indexed family of types: 2 

data Vec :: * —>■ N —>• * where 
Nil :: Vec a 0 

Cons ::Va(n::N).a-)' Vec an—)- Vec a (n + 1) 

2 Sensitive Haskell programmers may wonder why the kind of Vec is not N —> * —> *, since 
then Vec n is a monad for any n with the diagonal join, as shown in Subsection 5.2.4 (page 99). 
Unfortunately, this would make it harder to regard Vec as a type indexed by N, since Haskell 
treats type application as injective. 
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Here are some standard functions on vectors. The types of head and tail ensure 
they are never called on the empty vector, and lengths are tracked appropriately 
in the other cases. Most of the function definitions use polymorphic recursion 
and pattern-matching on GADTs, so their types must be specified. As discussed 
in Subsection 5.1.1 (page 90), the helper function for reverse implicitly requires a 
proof that (m + 1) + n ~ m + {n + 1), so additional constraint solving beyond 
the inductive definition of + is required. The lookup function demonstrates the 
use of n-types: the index m must be supplied at runtime, but statically known 
to be below the length n. 

head :: V(n :: N) a. Vec a (n + 1) —>• a 
head (Cons x _) = x 

tail :: V(n :: N) a. Vec a (n + 1) — > Vec a n 
tail (Cons _ xs) = xs 

append :: Va (m n :: N). Vec am—)- Vec an—)- Vec a (m + n) 

append Nil ys = ys 

append (Cons x xs) ys = Cons x (append xs ys) 
reverse :: V(n :: N) a. Vec a n —)• Vec a n 
reverse xs = help xs Nil 
where 

help :: V(m n :: N) a. Vec am—)- Vec a n —)• Vec a (m + n) 
help Nil ys = ys 

help (Cons x xs) ys = help xs (Cons x ys) 
lookup :: V(n :: N) a. n (m :: N). m < n => Vec a n —)• a 
lookup {0} (Cons x _) = a: 
lookup { k + 1} (Cons _ xs) = lookup { k } xs 

The fold for vectors has a rank-2 type, because for the Cons constructor it needs 
to abstract over the length m of the tail. Apart from the more informative type 
signature, it is essentially the same as the traditional foldr for lists. Indeed, it 
will erase to such a function at runtime. 

fold Vec N —)■ *) a (n :: N). 

/ 0 —>• (V(m :: N). a —>• / m —)• / (m + 1)) —)• Vec a n —>• / n 

foldVec n c Nil = n 

foldVec n c (Cons x xs) — c x (foldVec n c xs) 

As one would expect, foldVec Nil Cons is well-typed and equal to the identity 
function on vectors. Unfortunately the usual definition of append via a fold, 
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append' xs ys = foldVec ys Cons xs 


does not typecheck, because of the lack of type-level A-abstraction. It is possible 
to work around this, at the cost of some syntactic overhead, using a newtype: 

newtype Plus a m n = Plus {unPlus :: a (m + n)} 

append" :: Va (m n :: N) . Vec a m — > Vec a n —>• Vec a (m + n) 
append" xs ys = unPlus (foldVec (Plus ys) 

(\ z zs — y Plus (Cons z (unPlus zs))) xs) 


8.2 Merge sort 

I now implement merge sort, based on a similar example by Altenkirch et al. 
(2005) in the dependently typed programming language Epigram (McBride and 
McKinna, 2004). The type of the sorting function guarantees that it preserves 
the length of the vector and returns a sorted result, if anything. No proof ma¬ 
nipulation is necessary, and the program erases to a natural implementation of 
merge sort for lists of integers. I do not show that the result is a permutation of 
the input, as this would require a more expressive type system; Xi (2008) does so 
for quicksort in ATS. On similar lines, Xi (1998) gives an example of merge sort 
in Dependent ML that verifies the length of the input is preserved. 

Of course, Haskell’s type system does not check the totality of our programs, 
so this is only a partial correctness result. Higher-rank types allow me to express 
the fold-based recursion structure of the key functions, making the termination 
reasoning more obvious to the reader, if not the compiler. 

In principle, it is possible to express something similar using GADTs and 
type families, but the complexity of the implementation and the manual proofs 
involved would be much greater. Mu (2007) provides an impressive example that 
verifies length-preservation, but not ordering, in this manner. 

The point of this example is not that it is a verified implementation of merge 
sort, as there are many such programs already. Rather, it shows the utility 
of type-level numbers in Haskell and the ease with which they integrate with 
Haskell programming idioms (such as folds) and features (higher-rank types and 
polymorphic recursion). 

A Tree is a leaf-labelled binary tree indexed by the number of leaves. Its 
construction ensures that it is balanced, as the subtrees of each node differ in size 
by at most one. 
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data Tree :: * — y N —> * where 
Empty :: Tree a 0 
Leaf :: a —^ Tree a 1 

Even :: Va (n :: N) . 1 ^ n =>• Tree a n —>• Tree a n —>• 

Tree a (2 * re) 

Odd :: Va (re :: N). 1 ^ n => Tree a (to + 1) —>■ Tree a n —>• 

Tree a (2 * n + 1) 

Just like for vectors, the fold for trees uses higher-rank types. This version is 
slightly simplified, as it hides the distinction between even and odd nodes. 

foldTree :: V(/ :: N —>■ *) a (n :: N). 

/ 0 — y (a —>• / 1) —► (V(m n :: N)./ m —>• / n — > f (m+ n)) ■—} 
Tree a n —>• / n 

foldTree e l n Empty = e 

foldTree e l n (Leaf a) = l a 

foldTree e l n (Even x y) = n (foldTree e l n x) (foldTree e l n y) 

foldTree e l n (Odd x y) = n (foldTree el nx) (foldTree el ny) 

A tree can be built by folding over a vector, replacing Nil with Empty and 
inserting elements using the balance-preserving insert function: 

mkTree :: Va (n :: N). Vec a n —>• Tree a n 
mkTree = foldVec Empty insert 
where 

insert :: Va (n :: N). a —>• Tree a n —>• Tree a (n + 1) 

insert i Empty = Leaf i 

insert i (Leaf j) = Even (Leaf i) (Leaf j) 

insert i (Even l r ) = Odd (insert i l ) r 

insert i (Odd l r) — Even l (insert i r) 

A simple definition such as mkTree, which does not pattern-match on GADTs or 
use polymorphic recursion, does not need a top-level type signature. The bidirec¬ 
tional type inference algorithm is quite capable of inferring this type. However, I 
include the signature for consistency and clarity. 

Ordered vectors are indexed by lower and upper bounds, plus length. They are 
restricted to containing integers (by the n-quantifier). Ideally one should extend 
Z with top and bottom elements, to allow unbounded data. These restrictions 
derive from the limitations of the preprocessor; the theory given in Chapter 6 can 
support the general case. 
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data OVec :: Z —>■ Z —>■ N —>■ * where 
ONil ::V(Zu::Z).Z<tt=>OVecZuO 
OCons :: V(Z « :: Z) (n :: N). II (x :: Z). I x => 

OVec x u n —^ OVec Z tt(nNa) 

Given two ordered vectors, the merge function combines them to produce a 
single ordered vector. It uses the syntax for guards that introduce local con¬ 
straints described in Subsection 5.2.7. The second guard is redundant, but to see 
this the implementation would need to negate the results of previous tests when 
checking patterns, which is not currently supported. 

merge:: \/ (l u :: Z) (m n ::N). 

OVec l u m —>• OVec l u n —>• OVec l u (m + n) 
merge ONil ys = ys 

merge xs ONil = xs 

merge (OCons {x} xs) (OCons {y} ys) 

| {x 4 y} = OCons {x} (merge xs (OCons {y} ys)) 

| {x > y} = OCons {y} (merge (OCons { x } xs) ys) 

The type In l u represents integers in the interval [l,u]: 

data In :: Z —> Z —> * where 

In :: V(Z u :: Z). II (x :: Z). (I < ^ u) In l u 

The flatten function converts a binary tree of numbers in an interval to an ordered 
vector on that same interval, by invoking the higher-rank fold over the tree, calling 
merge at each node and converting each leaf value into a vector of length 1 . 

flatten ::V(lu::Z) (m :: N). / ^ u => Tree (In l u) m —>• OVec / u m 
flatten = foldTree ONil invec merge 

where invec :: V(/ u :: Z) . In l u —>• OVec / u 1 
invec (In {i}) = OCons {«'} ONil 

To merge sort a vector of numbers in an interval to produce an ordered vector, 
it is enough to construct and flatten a tree: 

sort :: V(Z u :: Z) (m :: N). I ^ u =>- Vec (In l u) m —>• OVec / u m 
sort = flatten o mkTree 

Now evaluating sort (Cons (In {3}) (Cons (In {1}) (Cons (In {2}) Nil))) produces 
the sorted list OCons {1} (OCons {2} (OCons {3} ONil)) as expected. 
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8.3 Left-leaning red-black trees 

I now move on to a more advanced example data structure, red-black trees. A 
left-leaning red-black tree is a self-balancing binary search tree, designed to give 
good performance for insertion, deletion and membership test operations. 3 Every 
node is coloured either red or black, subject to the following invariants: 

1 . All leaves, and both children of a red node, are black. 

2. The right child of a black node is black. 

3. Both children of an internal node have the same black height (the number 
of black nodes on any path to a leaf). 

There has been much research on implementing red-black trees in functional 
languages, building on foundations laid by Okasaki (1998), who dealt with inser¬ 
tion but not deletion. Might (n.d.) showed how to extend Okasaki’s implemen¬ 
tation to deletion by adding two extra colours for tracking temporary invariant 
violations. Yamamoto (2011) applied Okasaki’s work to left-leaning trees. 

Another strand of research focused on provably correct functional implemen¬ 
tations. Kahrs (2001) demonstrated an ingenious technique for enforcing the bal¬ 
ance invariant of red-black trees using the Haskell type system. Ek et al. (2011) 
used Agda to verify the binary search tree and colour invariants of left-leaning 
red-black tree insertion, and Oster (2011) extended this to deletion. 

Most implementations of red-black trees (both functional and imperative) 
work by constructing unbalanced trees and then applying a separate rebalancing 
operation. This does not work well when enforcing the invariants through the 
type system, because of the need to represent slightly malformed trees. Xi (2007) 
implemented red-black trees in ATS, following Okasaki’s approach, indexing trees 
by the number of red-red colour violations they contain, and requiring that well- 
formed trees contain no colour violations. In this implementation, I will use 
McBride and McKinna’s idea 4 of representing the path to the point where there 
would be an invariant violation using a Huet-style zipper. This avoids the need 
to represent trees that do not obey the invariants. 

The choice of left-leaning red-black trees here is not crucial. The technique of 
avoiding malformed trees using a zipper works well for other self-balancing binary 
search trees such as normal red-black trees or AVL trees. 

3 Left-leaning red-black trees were introduced by Sedgewick (2008), as a simplification of the 
original red-black trees of Bayer (1972), obtained by omitting invariant 2. Regarding red nodes 
as part of their parent nodes, an LLRBT is a 2-3 tree; a normal red-black tree is a 2-3-4 tree. 

4 Red-black tree insertion was implemented as an example with the Epigram 1 distribution. 
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8.3.1 Enforcing red-black tree invariants via types 

To keep track of colours in the type system, I define the following singleton 
GADT. This is a limitation of the preprocessor: in a full implementation, one 
could simply define an algebraic data type for colours (or use the booleans) and 
use its constructors promoted to the type level, which would be slightly neater. 

type Black = 0 
type Red = 1 
data Colour:: Z —>• * where 
Black:: Colour Black 
Red :: Colour Red 

The type RBTree represents well-formed red-black trees. Trees are indexed 
by lower and upper bounds, their colour and black height, and the type checker 
guarantees that all the invariants hold. Each leaf E stores a proof that its lower 
bound is strictly smaller than its upper bound, ensuring that the keys are stored in 
ascending order and there are no duplicated keys. There are separate constructors 
for red and black internal nodes (TR and TB respectively). The indexing ensures 
that the colour invariants are observed. A II-type is used to store the key x on 
an internal node, so that the ordering invariant can be maintained. 

data RBTree :: Z —>■ Z —>■ Z —>■ N —>■ * where 
E :: V(i j :: Z). i < j=> RBTree i j Black 0 
TR::V(ij::Z) (n :: N) . II (x :: Z). 

RBTree i x Black n —> RBTree x j Black n —> RBTree i j Red n 
TB::V(i j c :: Z) (n :: N). II (x :: Z) . 

RBTree i x c n —» RBTree x j Black n —v RBTree i j Black (n + 1) 

The interface that would exposed to the user of the red-black tree library hides 
the colour (always black) and the black height using the existential type RBT. 
However, the lower and upper bounds are visible. This distinguishes between 
invariants used only for the implementation of the library, which will change as 
nodes are inserted and deleted, from those relevant for the user. Alternative 
choices, such as concealing the bounds as well, are also possible. 

data RBT :: Z —y Z —>• * where 

RBT :: V(i j :: Z) (n :: N) . RBTree i j Black n RBT i j 
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Given the type RBTree, the corresponding type of one-hole contexts can be 
derived mechanically (McBride, 2001). These can be used to navigate a tree via 
a zipper (Huet, 1997). The type of one-hole contexts is indexed by two copies of 
the RBTree indices: those provided at the root, and those required at the hole. 
Since the root is always black, however, I can do away with one of the indices. 

data TreeZip :: Z —>• Z —>■ N —>■ — root indices 

Z —>■ Z —>■ Z —>■ N —* — hole indices 

* where 

Root:: V (i j :: Z) (n :: N). TreeZip i j n i j Black n 
ZRL :: V(f j i! / :: Z) (n n' :: N). II (x :: Z). 

TreeZip i' j' n' i j Red n —>• RBTree x j Black n —>• 

TreeZip i' j' n! i x Black n 
ZRR :: V(f' / i j :: Z) {n' n::N).U(x :: Z). 

RBTree i x Black n —>• TreeZip 0 f n' i j Red n —>• 

TreeZip i' / n' x j Black n 
ZBL :: V(i' / i j c :: Z) (n' n::N).U(x :: Z). 

TreeZip i* j' n' i j Black (n + 1) —>• RBTree x j Black n —> 

TreeZip i! f n' i x c n 

ZBR :: V(f' / i j c :: Z) (n' n :: N). II (x :: Z). 

RBTree i x c n —>• TreeZip i' j' n! i j Black (n + 1) —> 

TreeZip i' j' n' x j Black n 

Given a context and a tree that fits in the hole, the whole tree can be rebuilt 
by plug. This function is well-typed because the indexing discipline of TreeZip 
exactly matches the demands of RBTree. This also could be obtained for free 
using generic programming techniques (Loh and Magalhaes, 2011). 

plug :: V(f'/ i j c :: Z) (n n' :: N). 

RBTree i j c n —>• TreeZip %' f n! i j c n —>• RBTree %' f Black n' 
plug t Root = t 

plug t (ZRL {x} z r) = plug (TR {x} t r) z 

plug t (ZRR {x} l z) = plug (TR {x} / 1) z 

plug t (ZBL {x} z r) = plug (TB {x} t r) z 

plug t (ZBR {x} l z) = plug (TB {x} 11 ) z 
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8.3.2 Search 

When searching for a key x in a red-black tree, it can either be Found z t, where 
z is the context in which it was found and t is the subtree with x at the root, 
or Missing z, where z is the context that should have contained x. This detailed 
search result information will later be used to implement insertion and deletion. 

data Search Result ::Z—>-Z—>-Z—>-N—>•* where 
Found :: V(x i' j' i j c :: Z) (re' n::N). 

TreeZip i' j' re' i j c re -4 RBTree i j c re -f 

Search Result x $ / re' 

Missing :: V(x i' f i j :: Z) (re':: N). (i < x, x < j ) => 

TreeZip i' j' re' i j Black 0 —>• 

Search Result x %' / re' 

To search a tree, a context is built up by comparing the key x to the value y stored 
at each node, and descending into the appropriate subtree, until the key is found 
or a leaf is reached. The invariants make it hard to get wrong: if a conditional 
test is omitted, or an invalid result returned, the typechecker will object. 

search :: V(/' f :: Z) (re':: N). II (x :: Z). (£' <x,x < j ') 

RBTree i' / Black re' —> SearchResult x i' j' re' 
search {x} = help Root 
where 

help :: V(f j c :: Z) (re :: N). (i <x,x< j ) 

TreeZip 0 j' re' i j c n RBTree i j c re ^ 

SearchResult x f j' re' 

help z E = Missing z 

help z (TR {y} l r) \ {x < y} = help (ZRL {y} z r) l 

help z (TR {y} l r) \ {x ~ y} — Found z (TR {y} l r ) 

help z (TR {y} l r)\ {x> y} = help (ZRR {y} l z) r 

help z (TB {y} l r)\{x <y} = help (ZBL {y} z r) l 

help z (TB {y} l r) \ {x ~ y} — Found z (TB {y} l r) 

help z (TB {y} l r)\{x> y} = help (ZBR {y} l z) r 

The user of the library can be presented with a simple membership test: 

member:: V(i j :: Z). II (x :: Z) .(i<x,x< j ) => RBT i j —> Bool 
member {x} (RBT t) = case search {x} t of 
Missing _ —False 
Found —>• True 
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8.3.3 Insertion 

To insert an element into a red-black tree, use search to find the appropriate 
location, then add a new node and proceed back up the tree, rebalancing on 
the way. The InsProb datatype represents the kind of problems that may be 
encountered when rebalancing the tree: either it is on the level (inserting a tree 
into a hole of the correct black height, though not necessarily the same colour) 
or in a panic (because a red child would have a red parent). 

data InsProb :: Z —>• Z —>■ Z —>■ N —>■ * where 
Level :: V (i j c d :: Z) (n :: N). 

Colour c' —>■ RBTree i j d n —>• 

InsProb i j c n 

PanicRB :: V(* j :: Z) (n :: N). II (x :: Z). 

RBTree i x Red n —> RBTree x j Black n —> 

InsProb i j Red n 

PanicBR :: V(* j :: Z) (n :: N). n (x :: Z). 

RBTree i x Black n —> RBTree x j Red n —> 

InsProb i j Red n 

The insertRBT function searches for the element x, and if it is not present, calls 
the ins function defined below with the appropriate insertion problem. 

insertRBT :: V(i j :: Z) . II [xv.l). (i < x, x < j) => 

RBT i j —y RBT i j 

insertRBT {x} (RBT t) = solvelns (search {x} t) 
where 

solvelns :: V(n :: N). SearchResult x i j n —>• RBT i j 
solvelns (Missing z) = ins (Level Red (TR {a;} E E)) z 
solvelns (Found_) = RBT t 

To solve an insertion problem, move out through the context, updating the prob¬ 
lem appropriately at each step. While this definition looks intimidating (!), the 
types make it difficult to get wrong: the typechecker will object if a tree is ever 
constructed that breaks the invariants (either ordering or colouring). It is much 
easier to construct interactively than in batch mode. In fact, I first implemented 
it in Agda using the support for interactive construction, then transcribed it for 
inch. The Agsy proof search tool (Lindblad and Benke, 2006) is able to fill in 
many cases automatically, further reducing the effort involved. 
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ins :: V(Y f i j c :: Z) (n' n :: N). 

InsProb i j c n —>■ TreeZip i' j' n' i j c n —>• RBT %' f 


ins 

(Level 

Red (TR 

(4 

to t%)) Root = 

RBT (TB {x} to k) 


ins 

(Level 

Black t) 


Root = 

RBT t 


ins 

(Level 

Red t) 

(ZRL 

{x} zt') = 

ins (PanicRB {x} t f) z 


ins 

(Level 

Red t) 

(ZRR 

{x} t' z) - 

ins (PanicBR {x} t't) z 


ins 

(Level 

Black t) 

(ZRL 

{x} zt!) = 

ins (Level Red (TR {x} t 

t')) z 

ins 

(Level 

Black t) 

(ZRR 

{x} f z) = 

ins (Level Red (TR {x} t' 

t)) z 

ins 

(Level 

c t ) 

(ZBL 

{x}zt') = 

ins (Level Black (TB {x} 

t t')) z 

ins 

(Level 

Black t) 

(ZBR 

{x} t' z) — 

ins (Level Black (TB {x} 

t't )) z 

ins 

(Level 

Red (TR 

{y} 

k h)) (ZBR { 

x} E z) = 



RBT (plug (TB {?/} (TR { 1 } E 4 ) &) z) 
ins (Level Red (TR {y} k t 2 )) (ZBR {x} (TB {w} t t') z) = 
RBT (plug (TB {y} (TR {x} (TB {«,} t f) k) h) z) 
ins (Level Red (TR {y} k h)) (ZBR {x} (TR {w} t i') z) = 
ins (Level Red (TR {x} (TB {w} 11') (TB {y} ti i 2 ))) ^ 
ins (PanicRB {y} (TR {w} to ti) h) (ZBL {x} z t) — 
ins (Level Red (TR {y} (TB {w} to t\) (TB {x} t 2 t ))) ^ 
ins (PanicBR {y} to (TR {w} ti t^)) (ZBL {x} z t) = 
ins (Level Red (TR {w} (TB {y} to ti) (TB {x} ^ t ))) M 
ins (PanicRB {y} (TR {w} to h) fe) (ZBR {x} t z) = 
ins (Level Red (TR { w } (TB {x} t to) (TB {y} ti h))) z 
ins (PanicBR {y} t 0 (TR {w} ti t^)) (ZBR {x} t z) = 
ins (Level Red (TR {y} (TB {x} 11 0 ) (TB { w } t\ t 2 ))) z 


8.3.4 Deletion 

Deleting a key from a red-black tree is slightly more complicated than insertion. 
The search function positions the focus on the node to be deleted, then calls 
del Foe us, assuming the key exists. 

delete :: V(i j :: Z) . II (x :: Z). (i < x, x < j) => RBT i j —y RBT i j 

delete {x} (RBT t) — solveDel (search {x} t) 
where 

solveDel:: V(n :: N) . SearchResult x i j n —>• RBT i j 
solveDel (Missing ) = RBT t 
solveDel (Found z t) = delFocus t z 
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To delete the node at the focus, provided the right subtree has black height 1 
or more, the deleted key can be replaced with the minimum of its right subtree 
(using find Min defined below). The base cases (where the right subtree has black 
height zero) are handled individually. 

delFocus :: V(z' f i j c :: Z) {n! n :: N). 

RBTree i j c n —> TreeZip i' j' n' i j c n — >• RBT %' j' 
delFocus E z — RBT (plug E z) 

delFocus (TR { x } EE) z — RBT (plug E (wantBlack z)) 

delFocus (TB {x} E E) z = del E z 

delFocus (TB {x} (TR {y} E E) E) * = RBT (plug (TB {y} E E) z) 

delFocus (TR {x} to (TB {y} t x fa)) z — 

findMin (TB {y} t x t 2 ) (\{jfc} -)• ZRR {k} (wkTree to) z) 
delFocus (TB {x} to (TB {y} t x fe)) z 
findMin (TB {y} t x h) (\{k} ZBR {k} (wkTree to) z) 

The only context in which a red node can occur is the left child of a black node, 
which also accepts black nodes. Thus the wantBlack function can change the type 
from the former to the latter. 

wantBlack :: V(f'/ i j :: Z) (n 7 n::N). 

TreeZip i' j' n! i j Red n —>• TreeZip i' j' n! i j Black n 
wantBlack (ZBL {x} z r) — ZBL {x} z r 

Deletion may require the upper bound of a subtree to be weakened, which needs 
a traversal of its right spine to satisfy the type checker. This could be replaced 
with unsafeCoerce, since the inequality proofs being manipulated are not retained 
at runtime, so it is operationally the identity function. 

wkTree :: V (i j j' c n :: Z). j < f => RBTree i j c n RBTree i f c n 

wkTree E = E 

wkTree (TR {x} to t x ) — TR {a;} to (wkTree t x ) 

wkTree (TB {x} to h) = TB {x} to (wkTree t x ) 

The findMin function works inside the right subtree of the node whose key is 
being deleted, looking for the minimum key, which will be used to replace the 
deleted one. The zipper context abstracts over the (as yet unknown) minimum 
key. If the minimum is found on a red node, it can simply be removed and the 
tree be reconstructed. However, if the minimum is on a black node or leaf, then 
the del function is called to decrease the black height. 
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findMin :: V (f f i j c :: Z) (n! n :: N). RBTree i j c (n + 1) —> 

(II (k :: Z) . i < k =4* TreeZip %' f n' k j c (n+ 1)) —> 

RBT i'f 

findMin (TB {a;} E E) / = del E (/{s}) 

findMin (TB (TR {y} EE ) t) f = RBT (plug E (ZBL {x} (f {y}) t)) 
findMin (TR {x} (TB {y} EE) t) f = del E (ZRL {z} (f {y}) t) 
findMin (TR {x} (TB {y} (TR {k} E E) to) h) f = 

RBT (plug E (ZBL {y} (ZRL {a;} (/ {k}) t x ) t 0 )) 
findMin (TR {x} (TB {y} (TB {«,} to h) h) h) f- 
findMin (TB {«,} to h) (\{A:} ZBL {y} (ZRL {x} (/ {k}) t 3 ) h) 
findMin (TB {a;} (TB {y} to ti) fe) / = 

findMin (TB {y} t 0 h) {\{k} ZBL {x} (/ {k}) h) 

When deleting a black leaf (either directly or because it is the minimum in the 
right subtree of a deleted internal node), the black height must be decremented. 
Generally, the problem is to fit a tree of black height n into a hole that expects 
a tree of height n+ 1. The del function works its way upwards, rebalancing after 
deletion, in a similar way to ins. Again, this definition is much easier to write 
than to read, thanks to the automation tool Agsy (Lindblad and Benke, 2006). 
del:: V(f f i j :: Z) (re' n :: N). RBTree i j Black n —>• 

TreeZip i' j' n' i j Black (re + 1) —>• RBT i! f 
del t Root = RBT t 

del t (ZRL {a:} 2 (TB {y} to ti || = colourOf to 

(RBT (plug (TB {y} (TR {a;} t to) t\) (wantBlack z))) 

(\{w) t'o to RBT (P lu § (TR {w} (TB {a;} t t' 0 ) (TB {y} t” t } )) z)) 
del t (ZRR {a;} (TB {y} to ti) z) = colourOf to 

(RBT (plug (TB {a;} (TR {y} to h) t) (wantBlack z))) 

(\{w} t' Q t" -)• RBT (plug (TR {y} (TB {w} t' 0 t”) (TB {a;} % t)) z)) 
del t (ZBL {a;} z (TB {y} to t\)) = colourOf to 
(del (TBMCTR^jttoH) z) 

(\M t'o % -+ RBT (plug (TB {w} (TB {*} t & (TB {y} i" h)) z)) 
del t (ZBR {a;} (TR {y} to (TB {w} ti t 2 )) z) — colourOf ti 
(RBT (plug (TB {y} to (TB {x} (TR {w} h h) t)) z)) 

(\M t[ l'{ RBT (plug (TB {w} (TR {y} t 0 (TB {?;} t[ t’{)) 

(TB {x}t 2 t))z)) 

del t (ZBR {a;} (TB {y} to ti) z) = colourOf to 
(del (TB {a;} (TR {y} to ti) t) z) 

(\{w} ? 0 % RBT (plug (TB {y} (TB {w} /,' t") (TB {a;} k t)) z)) 
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The colourOf eliminator determines if a tree is red or black, and calls the 
corresponding argument. For red trees, it provides the children of the node to 
the callback. This reduces the number of cases in del, because each case depends 
on the colour of a subtree, but not whether it is a leaf or an internal node. 

colourOf :: Va (i j c n :: Z). 

RBTree i j c n —>• 

((c ~ Black) a) -4 

((c ~ Red) 4 >II(j:::Z). RBTree i x Black n — > 

RBTree x j Black n —> a) —> a 
colourOf E b g = b 

colourOf (TB { x }_) b g = b 

colourOf (TR {x} to h) b g = g {x} to ti 


8.4 Tracking time complexity 

Danielsson (2008) introduced the Thunk library for verifying the time complex¬ 
ity of purely functional data structures in the dependently typed programming 
language Agda. He indexes a monad by the number of computation steps re¬ 
quired to deliver a value in weak head normal form. Function definitions must 
be annotated with calls to an operation that increments this number. 

newtype Cost (n :: N) a = Hide {force :: a} 

The implementation of Cost and the primitive functions on it are hidden, 
because Cost is really a newtype with phantom type parameter n. This avoids 
runtime overhead, but if it was exposed to the user then the library invariants 
would be easily violated. Agda provides a language construct abstract to support 
this, and a similar abstraction barrier can be created in Haskell using modules. 

The return and bind functions witness the fact that Cost is a monad indexed 
by the monoid (N, +). That is, any value can be computed in no steps, and if 
some a can be computed in m steps, and used to compute some b in n steps, then 
the overall computation takes m + n steps. 

return :: a — Cost 0 a 
return = Hide 

bind :: V(m n :: N) a b. Cost m a —> (a —>• Cost n b) —>• Cost (m + n) b 
bind (Hide x) f = wait (/ x) 


187 



If a value can be computed in m steps, then it can be computed in n steps for 
any n larger than m. Unlike Danielsson’s version, which requires the caller to 
specify a number of steps to wait, this exploits the inequality constraints of inch 
to provide a more flexible interface. 

wait :: V(m n :: N) a.m ^ n => Cost m a —>• Cost n a 
wait (Hide a) = Hide a 

A crucial part of the methodology is to annotate every line of every function 
definition being counted with a call to tick, which increments the counter. 

tick :: V(n :: N) a. Cost n a —>• Cost (n+ 1) a 
tick = wait 

A useful helper function, returnW, allows a value to be injected into the monad 
with an arbitrary weakening of the upper bound. 

returnW :: V(re :: N) a. a —* Cost n a 
returnW x — wait (return x) 

Danielsson’s approach works well for verifying the time complexity of the merge 
sort and red-black tree operations defined in the previous sections. The inch 
constraint solver is able to deal with the proof obligations automatically, rather 
than requiring the user to supply proofs of trivial arithmetic properties. There are 
some obligations on the user of the library not captured by the types: every user 
function must be annotated with calls to tick, the force function must not occur 
inside code being timed, and library functions must not be partially applied. 

To show how the approach works, I will reimplement red-black tree search 
with complexity annotations, proving that the time for the membership test is 
linear in the height of the tree. 5 


5 That is, it is logarithmic in the number of elements. 



First, the data type declaration for the zipper must have an extra index, to 
count its depth. This is needed to express some of the complexity invariants that 
the helper functions satisfy. 

data TreeZip':: Z —> Z —>• N —>• — root indices 

Z—>-Z—>-Z—>-N—>• — hole indices 
N —>• — depth 

* where 

Root':: V(i j :: Z) (n :: N). TreeZip' i j n i j Black n 0 
ZRL' :: V(| j i' f :: Z) (n ri d :: N) . II (x :: Z). 

TreeZip' f' f n' i j Red n d —> RBTree x j Black n —> 

TreeZip' i' j' v! i x Black n (d+ 1) 

ZRR' :: V(*' f i j :: Z) (n' n d :: N). II (x :: Z). 

RBTree i x Black n — > TreeZip' %' f n' i j Red n d —> 

TreeZip' i' j' n! x j Black n (d+ 1) 

ZBL' :: V(i' f i j c :: Z) (n' n d :: N). II (x :: Z). 

TreeZip' i' j' n' i j Black (n + 1) d — v RBTree x j Black n —>■ 
TreeZip' f / n' i x c n {d + 1) 

ZBR' :: V(*' j' i j c :: Z) (n' nd::N).n(i::Z). 

RBTree i x cn^r TreeZip' i' j' n' i j Black (n + 1) d —>• 

TreeZip' i' j' v! x j Black n (d+ 1) 

The Search Result type packs up the extra index, but is otherwise unchanged. 

data Search Result' ::Z—>-Z—>-Z—>• N —>• * where 
Found' :: V(x i' j' i j c :: Z) (n' n d :: N). 

TreeZip' %' f n' i j c n d —>• RBTree i j c n —>• 

Search Result' x i' j' n! 

Missing' :: V(x i' j' i j :: Z) (n'd :: N). (i < x, x < j) =>• 

TreeZip' %' f n' i j Black 0 d —> 

Search Result' x i' j' v! 

The searchCost function returns a result in the Cost monad, showing that it takes 
2n/ 4*2 steps where n' is the black height of the tree. Some work is needed to 
choose the appropriate invariant to be maintained in the helper function. In 
this case, the invariant depends on the colour of the tree, so a separate helper 
function is needed when the subtree is black. The lines of the helper functions 
are annotated with calls to tick. Pure values are inserted into the Cost monad 
with returnW. The wait function is used to weaken a bound where the result is 
computed more quickly than the type requires. 







searchCost :: V(f / :: Z) ( n ':: N) .11 (x :: Z). (f < x, x < f) 

RBTree i- f Black to' —>■ 

Cost (2 * to' + 2) (SearchResult' x i' f to') 
searchCost {x} t = tick (helpB Root' t) 
where 


help :: V ( z jc::Z) (to d::N). 

((1 -f (2 * n) + d) ^ (2 * to'), i <-x,.x < j) => 

TreeZip' ■/' f to' i j c n d —>• RBTree i j c n —>• 

Cost (2 + 2 * to) (SearchResult' x i' j' n') 
help zE = tick (returnW (Missing' 2 )) 

help z (TR {y} / r) | {x < y} = tick (helpB (ZRL' {y} z r) l ) 

help z (TR {y} l r) \ {x ~ y} = tick (returnW (Found' z (TR {y} l r))) 

help z (TR {y} l r)\{x> y} = tick (helpB (ZRR' {y} l z) r ) 

help z (TB {y} l r) \ {x < y} = tick (wait (help (ZBL' {y} z r) l )) 

help z (TB {y} l r) \ {x ~ y} = tick (returnW (Found' z (TB {y} l r))) 

help z (TB {y} l r) \ {x > y} = tick (wait (help (ZBR' {y} l z) r)) 

helpB ::V(ij::Z) (n d :: N). 

(((2 * n) + d) ^ (2* n'), i <x,x< j) 

TreeZip' i' j' n' i j Black n d —>• RBTree i j Black n —> 

Cost (2 * to + 1) (SearchResult' x i' j' to') 
helpB z E = tick (returnW (Missing' z)) 

helpB z (TB {y} l r) \ {x < y} = tick (help (ZBL' {y} z r) l ) 

helpB z (TB {y} l r) | {x ~ y} = tick (returnW (Found' z (TB {y} l r))) 

helpB z (TB {y} l r) \ {x > y} = tick (help (ZBR' {y} l z) r) 

The membership test can be implemented as before, inserting the necessary 

monadic plumbing and calls to tick. Thus it returns a result in 2n + 4 steps. 

memberCost:: V(£ j :: Z) (to :: N). II (x :: Z) . (i < x, x < j) 

RBTree i j Black n —>■ Cost (2 * to + 4) Bool 
memberCost {x} t = tick (bind (searchCost {x} t) f) 
where 

/ :: Search Result' x i j n —>• Cost 1 Bool 
/ (Missing' _) = tick (return False) 

/ (Found'_) = tick (return True) 

The force function can be used to escape the Cost monad and acquire a value. 
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member':: V(£ j :: Z). II (x :: Z) .(i<x,x< j) =>• RBT f j —y Bool 
member' {x} (RBT t) = force (memberCost {x} t) 


This approach can be used to show that both insertion and deletion are linear 
in the black height of the tree. The types given to the main functions are: 

insert :: V(i j :: l) (n :: N). II (x :: Z). (i < x,x < j) => 

Tree i j Black n —> Cost (4 * n + 6) (RBT i j ) 
delete :: V(£ j :: Z) (n :: N). II (x :: Z). (i < x, x < j) => 

Tree i j Black n -4- Cost (5 * n + 6) (RBT i j) 

As in the member example, the main difficulty is in choosing appropriate in¬ 
variants; the annotation is routine. Interactive program construction makes this 
easier, as it enables exploratory programming. 

8.5 Units of measure 

This section demonstrates a use for type-level integers, rather than natural num¬ 
bers: a library for representing units of measure. Unlike the approach taken in 
Chapter 3, which requires a language extension but can support an arbitrary set 
of base units, this library can be implemented using existing features of inch, but 
the base units must be fixed ahead of time. Moreover, type errors will reveal 
the underlying representation of units, rather than being expressed in an easy- 
to-understand format. The dimensional package of Buckwalter (n.d.) is a much 
more comprehensive implementation of units of measure using this approach, but 
with type-level integers implemented via existing features of GHC Haskell. 

The Unit constructor has arguments for the powers of three base units (metres, 
seconds and kilograms). A real units of measure implementation would supply 
more base units, but the number would still be fixed. The Quantity newtype wraps 
a numeric value, and has a phantom type parameter that will be instantiated with 
some application of Unit. This separation makes it easy to write functions that 
are completely polymorphic in the units. 

d3td Unit:: Z — y Z — y Z — y * 
newtype Quantity u a = Q {value :: a} 

The Q constructor should not be exported from the module in which it is 
defined, in order to prevent clients of the library from changing units arbitrarily. 
Instead, all access must be through the functions defined below. 
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In the full inch system, with support for promoted datatypes, Unit would be a 
data constructor rather than a type constructor. Type synonyms can be defined 
for common units. If type families or type-level functions were available, one 
could define operations to combine units (such as multiplication of units). 

type Dimensionless = Unit 0 0 0 

type Metres = Unit 10 0 

type Seconds = Unit 0 10 

type Kilograms = Unit 0 0 1 

type MetresPerSecond = Unit 1 (—1) 0 
type Newtons = Unit 1 (-2) 1 

Users of the library will have access to smart constructors, which wrap the un¬ 
derlying newtype constructor Q, but specify the units. 

dimensionless :: a —> Quantity Dimensionless a 
metres :: a —>- Quantity Metres a 

seconds :: a —)► Quantity Seconds a 

kilograms :: a —» Quantity Kilograms a 
(dimensionless, metres, seconds, kilograms) = (Q, Q, Q, Q) 

The usual arithmetic operations can be defined on quantities, with the types 
ensuring that the units are respected. However, Quantity u a cannot be made an 
instance of the Num typeclass, because multiplication does not preserve units. 

plus :: Num a => Quantity u a —>• Quantity u a —>■ Quantity u a 
plus (Q x) {Qy) = Q (x + y) 

minus :: Num a Quantity u a —>• Quantity u a —>• Quantity u a 
minus (Q x) (Q y) = Q (x - y) 

The type signatures of the following operations would be significantly simpler if 
type-level functions could be defined. 

times ::V (m s g m' s' g':: Z) a. Num a =>• 

Quantity (Unit m s g) a —* Quantity (Unit m' s' g') a 
Quantity (Unit (m + m') (5 + s') (g + g')) a 
times (Q x) (Q y) = Q {x*y) 
inv :: V(m 5 ^ Z) a. Fractional a => 

Quantity (Unit m s g) a —>• Quantity (Unit (— m) (— s) (—g)) a 
inv (Q x) = Q (recip x) 
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over:: V(m s g ml s' g' :: Z) a . (Num a, Fractional a) =>• 

Quantity (Unit m s g) a —>• Quantity (Unit ml s' g') a —> 

Quantity (Unit (m — m') (5 — s') (g — g')) a 
over x y = times x (inv y) 
pow :: V(m s g :: Z) a. Fractional a =>- 
II (A; :: N) . Quantity (Unit m s g) a —> 

Quantity (Unit (A; * m) (A; * 5 ) (A; * < 7 )) a 
pow {A;} (Q x) = Q (x~~k) 

Scaling a quantity by a dimensionless constant is useful: 

scale :: Num a =>• a —> Quantity u a —>• Quantity u a 
scale £ (Q y) = Q (x * y) 
minutes = scale 60 o seconds 
hours = scale 60 o minutes 

More generally, unit prefixes can be written as transformers of the constructors 
that scale by an appropriate constant: 

type Prefix u a = (a —>• Quantity u a) —> a —>• Quantity u a 

prefix :: Num d=^(t4 Prefix u a 

prefix nf = scale no f 

kilo = prefix 1000 

centi = prefix (recip 100 ) 

milli = prefix (recip 1000 ) 

This allows prefixed units to be expressed neatly: 

km = kilo metres 
cm = centi metres 
mm = milli metres 

Finally, a special case of flipped application allows expressions such as units 3 cm 
and units 15 km ‘over‘ units 3 hours. 

units :: a —>• (a —>• Quantity u b) —>• Quantity u b 
units x f = f x 

As an example of using the library, here is a variant of the function from the 
introduction to Chapter 3 that calculates the distance travelled over time by an 
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object with a fixed initial velocity and constant acceleration. The top-level type 
annotation is entirely optional. 

distanceTravelled :: (Num a, Fractional a) =>• 

Quantity Seconds a —>• Quantity Metres a 
distanceTravelled t = plus (times vel t) (times accel (pow {2} t)) 
where 

vel = over (units 20 metres) (units 1 seconds) 

accel = over (units 36 metres) (pow {2} (units 1 seconds)) 

Kennedy (2010, §3.10) gave an example of a function whose type cannot be 
inferred by the units-of-measure type system in F#, because of difficulties with 
generalisation, as explained in Subsection 3.0.1. 

trouble — \ x —> let d = over x 

in (d mass, d time) 

where 

mass = units 5 kilograms 
time = units 3 seconds 

The inch system has no trouble inferring the most general type for this function 

trouble :: Va (m :: Z) (s :: Z) (g :: Z). 

(Num a, Fractional a) =>■ 

Quantity (Unit m s g) a —>• 

(Quantity (Unit m s (g — 1)) a, Quantity (Unit m (s — 1) g) a ) 

although the fixed basis of units means it is more limited than Kennedy’s solution 
or the algorithm in Chapter 3. 
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Chapter 9 
Conclusion 


The inch language described in this thesis is an experiment in re-imagining GHC 
Haskell. It shows how insights from work on dependent type theory can con¬ 
tribute to the development of Haskell’s type system, intermediate language and 
elaboration process. It is not intended as a finished product or a rival system; 
rather, I have investigated some of the ways in which Haskell might develop. 

Haskell as implemented in GHC is a moving target, with new language ex¬ 
tensions being introduced frequently. The recent enrichment of the kind system 
with polymorphism and datatype promotion paves the way for the identification 
of kinds with types, a key aspect of the design of inch, and work to implement 
this is ongoing. Weirich et al. (2013) and the evidence language of Chapter 6 
show that this gives a reasonable core language; the discussion of elaboration in 
Chapter 7 gives some idea of how type inference will continue to work. 

The addition of n-types to the language offers the possibility of significantly 
simplifying Haskell programming with dependent types. In particular, it avoids 
the need for singleton constructions that result in many incompatible names for 
essentially the same object. If Haskell’s type system is to become more depen¬ 
dent, the key requirement is for the operational semantics of the term and type 
levels to be aligned, breaking the strict distinction between functions and type 
families. The shared functions of this thesis offer a possible way forward. While 
not requiring the identification of kinds and types, n-types are much more useful 
if the identification is made, since then indexed datatypes can be quantified over. 

Another key aspect of Chapter 7 is the increased flexibility it offers for which 
arguments are expected to be inferred by the machine. Milner’s compromise, 
particularly the insistence that type-level expressions be invisible in terms, is 
no longer tenable in a world of advanced type-level features. By providing the 
machine with a small amount of help, we can gain significant expressive power. 




The case for permitting explicit type application and quantification grows ever 
stronger. Il-types benefit from case-by-case decisions on whether they should be 
explicit or implicit, and extending the same mechanism to V-quantifiers seems 
natural. In any case, wherever an argument is supposed to be inferred by the 
machine, it should be possible for the user to supply it. 

Type inference and unification with nontrivial equational theories has been a 
key theme of the first part of this thesis, including the theory of abelian groups for 
units of measure in Chapter 3 and the theory of /377-conversion in Chapter 4. A 
desirable feature for a system of type-level numbers is automatically solving the 
constraints that arise, and the abelian group structure of the integers provides 
a starting point for this, though the presence of local hypotheses complicates 
matters and more research is needed. As I have outlined, the careful management 
of variable scope (using dependency-ordered contexts) can help make it clear how 
to solve constraints in a most general fashion. 

Elaboration of full-spectrum dependently-typed languages is another topic in 
need of further work, as practical implementations are not always theoretically 
well-understood. I hope that the higher-order unification algorithm in Chapter 4 
may provide a useful base for describing elaboration more precisely. 
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Appendix A 

Reference implementation of 
Hindley-Milner type inference 


In this appendix and the two that follow I will present reference implementa¬ 
tions for the unification and type inference algorithms described in Part I of this 
thesis. The implementations are presented in literate Haskell, and I will take 
slight liberties with the Haskell syntax. In particular, I will use italicised capital 
letters (e.g. A) for Haskell variables, while sans-serif capital letters (e.g. A) will 
continue to stand for data constructors. This allows me to retain more of the 
syntactic conventions of the earlier chapters, such as using 0 for a metacontext 
and A for an object language type. I will omit boilerplate code such as module 
import lists and straightforward typeclass instances, and routine support code 
for pretty-printing and testing. 

The code has been tested using version 7.6.3 of the Glasgow Haskell Compiler, 
with version 2013.2.0.0 of the Haskell Platform and version 0.6 of the Strathclyde 
Haskell Enhancement (McBride, 2010b). It is available online 1 and with the 
electronic version of this thesis. In addition to the standard libraries, the Binders 
Unbound library of Weirich et al. (2011b) is used to represent syntax with names 
and bindings, deriving o-equivalence and substitution functions automatically. 

In this appendix, I implement syntactic unification and Hindley-Milner type 
inference, as described in Chapter 2. Section A.l gives datatypes representing 
types, terms and contexts in the object language; Section A.2 gives the implemen¬ 
tation of unification, and this is used in Section A.3 to implement type inference. 
Finally, Section A.4 contains an implementation of elaboration from Hindley- 
Milner terms into System F, based on a zipper. 

1 https://github.com/adamgundry/type-inf erence/ 



A.l Representation of types and terms 


This section implements type, contexts and terms, as in Section 2.1 (page 11). 

The datatype Type represents types of the object language, which may contain 
metavariables M and variables V as well as functions and a base type. The Name 
constructor is provided by the Binders Unbound library. 

data Type = M (Name Type) | V (Name Type) | Type -> Type 

The fmv function computes the free metavariables of a type. 

fmv :: Type —>• Set (Name Type) 

fmv (M a) = {a} 

fmv (V a) =0 

fmv (r —> v) — fmv r U fmv v 

The datatype Scheme represents type schemes. Binding variables uses a locally 
nameless representation where bound variables have de Bruijn indices and free 
variables (those bound in the context) have names (McBride and McKinna, 2004). 

data Scheme = T Type | All (Bind (Name Type) Scheme) 

Bwd is the type of backwards lists with • for the empty list and :< for snoc. 
Lists are traversable functors, and monoids under concatenation (©), in the usual 
way. Datatype declarations are cheap, so rather than reusing the forwards list 
type [], I prefer to make the code closer to the specification. 

data Bwd a = • | Bwd a:< a 

Contexts are backwards lists of entries, which are either metavariables E (pos¬ 
sibly carrying a definition), term variables Z or generalisation markers A con¬ 
text suffix contains only metavariable entries, and can be appended to a context 
with the ‘fish’ operator (<x). 

type Context = Bwd Entry 

type Suffix = [(Name Type, Decl Type)] 

data Decl v = HOLE | DEFN v 

data Entry = E (Name Type) (Decl Type) | Z (Name Tm) Scheme | , 

(<x) :: Context — >■ Suffix — y Context 

0 <X ((a, d) : es) — (6 :< E a d) <X es 
0 <X [] = 0 
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The Contextual monad represents computations that can mutate the context, 
generate fresh names and throw exceptions. It thus encapsulates the effects 
needed to implement unification and type inference. I will use the throwError 
operation in the monad to abort due to ‘expected’ errors, such as impossible uni¬ 
fication problems, and the Haskell built-in error for violations of invariants that 
would indicate bugs in the implementation itself. 

newtype Contextual a = Contextual 

(StateT Context (FreshMT (ErrorT String Identity)) a) 

The popL function removes and returns an entry from the metacontext. 

popL :: Contextual Entry 
popL = do & :< e <- get 
put 0 
return e 

The fresh Meta function generates a fresh metavariable name and appends a 
HOLE to the context. 

freshMeta :: String —>• Contextual (Name Type) 
fresh Meta a = do a <- fresh (s2n a) 

modify (:<E a HOLE) 
return a 

The datatype Tm represents terms in the object language. As with type 
schemes, it uses a locally nameless representation. 

data Tm = X (Name Tm) | App Tm Tm 

| Lam (Bind (Name Tm) Tm) | Let Tm (Bind (Name Tm) Tm) 

The Contextual monad supports the find function, which looks up a term 
variable in the context and returns its scheme. 

find :: Name Tm Contextual Scheme 
find x = get »= help 
where 

help :: Context —>■ Contextual Scheme 

help • = throwError $ "Out of scope: " -H- show x 

help (0 :< Z y a) \ x = y — return a 
help (0 :< _) = help 0 
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The inScope operator runs a Contextual computation with an additional term 
variable in scope, then removes the variable afterwards. 

inScope :: Name Tm ^ Scheme —>• Contextual a —> Contextual a 
inScope x a m = do modify (:<Z x a) 
a <— m 

modify dropVar 
return a 

where 

dropVar • = error "Invariant violation" 

dropVar (O :< Z y _) | x = y = 6 

dropVar (6 :< e) = dropVar 6 :< e 


A.2 Unification 

Having set up the necessary data structures, I will now implement the unification 
algorithm of Section 2.2 (page 19). 

The onTop operator delivers the typical access pattern for contexts, locally 
bringing the top variable declaration into focus and working over the remainder. 
The local operation /, passed as an argument, may restore the previous entry, or 
it may return a context extension (containing at least as much information as the 
entry that has been removed) with which to replace it. 

data Extension = Restore | Replace Suffix 

onTop :: (Name Type —>• Decl Type —>• Contextual Extension) 

—> Contextual () 

onTop / = popL :^= \ e —> case e of 
E a d ^ f a d :»= \ m —> case m of 
Replace E —»> modify (<X E) 

Restore —>• modify (:<e) 

_ —> onTop / » modify (:<e) 

restore :: Contextual Extension 
restore = return Restore 
replace :: Suffix —>• Contextual Extension 
replace = return o Replace 
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The unify function actually implements unification. This proceeds structurally 
over types. If it reaches a pair of metavariables, it examines the context, using 
onTop to pick out a declaration to consider. Depending on the metavariables, it 
then either succeeds, restoring the old entry or replacing it with a new one, or 
continues with an updated constraint. 

unify :: Type —>■ Type —* Contextual () 
unify (t 0 -> Ti) (u 0 —> Vi) — unify r 0 u 0 » unify 7f V\ 
unify (M a) (M (3) = onTop $ \ 7 d — > case 
(7 = a, 7 = /3, d ) of 

(True, True, _ ) —* restore 

(True, False, HOLE ) replace [(a, DEFN (M 0))] 

(False, True, HOLE ) ->• replace [(/3, DEFN (M a))] 

(True, False, DEFN r) — > unify (M /3) r > restore 

(False, True, DEFN r) —>■ unify (M a) t » restore 

(False, False, _ ) unify (M a) (M /3) > restore 

unify (M a) r = solve a [] r 

unify t (M a) = solve a [] r 

unify _ _ = throwError "Rigid-rigid mismatch" 

The solve function is called to unify a metavariable with a rigid type (one that 
is not a metavariable). It works similarly to the way unify works on pairs of 
metavariables, but must also accumulate a list of the type’s dependencies and 
push them left through the context. It performs the occurs check and throws an 
exception if an illegal occurrence (leading to an infinite type) is detected. 

solve :: Name Type —> Suffix -4 Type —>■ Contextual () 
solve a E r = onTop $ 

\ 7 d ->• case 


(7 = a, 

, 7 e fmv 

t, d 

) of 

hi 


DEFN v 

') — > modify (<X S) 

» unify (subst 7 v (M a)) (subst 7 v r) 




» restore 

(True, 

True, 

HOLE 

) — >• throwError "Occurrence detected 

(True, 

False, 

HOLE 

)^ replace {8 O [(a, DEFN r)]) 

(False, 

True, 

HOLE 

) — >■ solve a ((7, HOLE) : 8) t 




» replace [] 

(False, 

False, 

HOLE 

) —y solve a 8 t 


» restore 
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A.3 Type inference 

Building on the implementation of unification in the previous section, I now 
implement the type inference algorithm described in Section 2.3 (page 23). 

The metaBind and metallnbind functions extend the bind and unbind functions 
provided by the Binders Unbound library, so that binding a metavariable converts 
it into a variable, and vice versa. 

metaBind :: (Alpha t, Subst Type t) =£ 

Name Type —>•£—>• Bind (Name Type) t 
metaBind a = bind a o subst a (V a) 
metallnbind :: (Alpha t, Subst Type t, Fresh m) =$■ 

Bind (Name Type) t —> m (Name Type, t) 
metallnbind b = do (a, t) <— unbind b 

return (a, subst a (M a) t) 

Specialisation of type schemes is implemented by the specialise function, which 
unpacks a scheme with fresh metavariables for the bound variables. 

specialise :: Scheme —>• Contextual Type 
specialise (T r) = return r 
specialise (All b) = do (/3,a) metallnbind b 
modify (:<E f3 HOLE) 
specialise a 

Generalisation turns a type into a scheme by ‘skimming’ entries off the top of 
the metacontext. The generaliseOver control operator runs a Contextual computa¬ 
tion in a new locality (extending the context by ?), then generalises the resulting 
type until it finds the , again. This depends on the function which generalises 
a suffix of metavariables over a type to produce a scheme. 
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generaliseOver:: Contextual Type —» Contextual Scheme 
generaliseOver x = do modify (:<,) 
r <— x 

E <— skimContext [] 
return (E ft r) 

where 

skimContext:: Suffix —>• Contextual Suffix 
skimContext E = popL »= \ e —> case e of 
E ad —> skimContext ((a, d) : E) 

9 —>• return E 

(ft) :: Suffix ->• Type —> Scheme 
[] f t = T r 

((a, HOLE) : E) f|- r = All (metaBind a (E ft r)) 

(( a , DEFN v) : E) ffr = subst a v (E ft r) 

Finally, the infer function implements the type inference algorithm. It pro¬ 
ceeds structurally through the term, following the rules in Figure 2.9 (page 26) 
and using the monadic operations defined earlier. 

infer ::Tm -> Contextual Type 

infer (X x) = find x »= specialise 

infer (Lam b) = do (x, t) unbind b 

a M ($) fresh Meta "alpha" 

v <— inScope i(Ta)$ infer t 

return (a -» v) 
infer (App / s) = do x i n f er / 

v <— infer s 

(5 <— M ($)freshMeta "beta" 

unify x(v-> P) 
return p 

infer (Let s b) = do a <- generaliseOver (infer s) 

(x, t) <— unbind b 
inScope x a $ infer t 
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A.4 Elaboration, zipper style 

In this section, I implement the zipper-based elaboration algorithm described in 
Section 2.4 (page 27). This transforms source language terms Tm (defined in 
Section A.l) into System F terms FTm, represented thus: 

data FTm = VarF (Name FTm) | AppTm FTm FTm | AppTy FTm Type 
| LamTm Scheme (Bind (Name FTm) FTm) 

| LamTy (Bind (Name Type) FTm) 

As described in the text, context entries now consist of metavariables and layers: 

data TermLayer = AppLeft () Tm 

| AppRight (FTm, Type) () 

| LamBody (Name Tm,Type) () 

| LetBinding () (Bind (Name Tm) Tm) 

| LetBody (Name Tm) (FTm, Scheme) () 
data Entry = E (Name Type) (Decl Type) | L TermLayer 

Most functions from the previous sections, including the unification algorithm, 
remain unchanged. The find function, which looks up a term variable in the 
context and returns its type scheme, is easily adapted to the new structure: 

find :: Name Tm —> Contextual Scheme 
find x = get »= help 
where 

help :: Context ->• Contextual Scheme 
help • = throwError $ "Out of scope: " -H- show x 
help (0 :< L (LamBody (y, r) ())) | x = y — return (T r) 
help (0 :< L (LetBody y (_, a) ())) | x = y — return a 
help (<9 :< _) = help 0 

The specialise function takes an elaborated term and its scheme, and applies the 
term to fresh metavariables to produce a witness of the specialised type. 

specialise :: FTm —>• Scheme —> Contextual (FTm, Type) 
specialise i(T r) = return (t,r) 
specialise t (All b) = do (/3,a) <- metaUnbind b 
modify (:<E/3 HOLE) 
specialise (t 'AppTy' M (3) a 
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Now elaboration can be implemented as a tail-recursive function elab. To 
elaborate a variable, it looks up the type scheme and instantiates it with fresh 
metavariables, then calls the next function to navigate the zipper structure and 
find the next elaboration problem. For A-abstractions, applications and let- 
bindings, it extends the zipper and elaborates the appropriate subterm. 

elab :: Tm —)■ Contextual (FTm, Type) 
elab (Xi) = do a find x 

next [] ==c specialise (VarF x) a 
elab (Lam b ) = do (x, t ) <- unbind b 

a <— fresh Meta "alpha" 
modify (:<L (LamBody (x, M a) ())) » elab t 
elab (/ 'App' a) = modify (:<L (AppLeft () a)) » elab / 
elab (Let s b) = modify (:<L (LetBinding () b)) » elab s 

The next function is called with the term at the current location and its type. 
It navigates through the zipper structure to find the next elaboration problem, 
updating the current term and type as it does so. The accumulator E collects 
metavariables that encountered along the way. These are reinserted into the 
context once the new problem is found, or if a LetBinding layer is encountered, E 
contains exactly the metavariables to generalise over. 


next:: Suffix —> (FTm, Type) — 
next E ( t,r) = optional popL 2 
Just (L (AppLeft () a)) 


Just (L (AppRight (/, c) ())) 


Just (L (LamBody (x,v) ())) 

Just (L (LetBinding () b)) 


Just (L (LetBody x ( s,a ) ())) 
Just (E a d ) 

Nothing 


Contextual (FTm, Type) 

= \ e —> case e of 

—>■ do modify (<X E) 

modify (:<L (AppRight (t,r) ())) 
elab a 

—> do modify (<X E) 

/3 <— M ($)freshMeta "beta" 

unify cr (r -> 0) 

next [ ] (/ 'AppTm' t, (3) 

—> next E ( Xx: v. t, v -» r) 

—>• do (x, w) <— unbind b 

let (t 1 , a) = (A E. t,E ft r) 
modify (:<L (LetBody x ( t',cr ) ())) 
elab w 

—y next E (Xx: a. t 'AppTm' s, r) 

—> next ((a, d) : E) (t , r) 

—>• modify (<X E) » return ( t,r ) 
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Appendix B 

Reference implementation of 
units of measure 


This appendix extends the implementation of unification in Appendix A to sup¬ 
port the units of measure of Chapter 3. Section B.l introduces the data types 
representing units of measure in normal form, using the signed-multiset library 
of Holdermans (2013). Section B.2 extends the representation of types and con¬ 
texts from Section A.l to support the syntax of units. The implementation of 
unification for units of measure is given in Section B.3, and this is used to imple¬ 
ment type unification in Section B.4. There is no change to the implementation of 
type inference from Section A.3, other than using the new unification algorithm. 

B.l Representation of units of measure 

I begin by introducting the semantic representation of units of measure, along 
with operations on them, as described in Section 3.1 (page 35). A unit of measure 
is represented as a Unit value with signed multisets of metavariables and constants. 
For simplicity, the type of base units is fixed. 

data Unit = Unit (SignedMultiset (Name Type)) (SignedMultiset BaseUnit) 
data BaseUnit = METRE | SEC | KG 

The mkUnit function creates a unit from lists of powers of metavariables and 
base units. As a special case, metaUnit creates a unit from a single metavariable. 

mkUnit:: [(Name Type, Int)] —>• [(BaseUnit, Int)] —>■ Unit 
mkUnit vs bs = Unit (fromList vs) (fromList bs) 
metaUnit:: Name Type —>■ Unit 
metaUnit a = mkUnit [(a, 1)] [] 



Utility functions determine if a unit is the identity or constant, the number 
of variables it contains, and the power of a metavariable in it. 

isldentity :: Unit -4 Bool 
isldentity (Unit vs bs ) = null vs A null bs 
isConstant:: Unit -4 Bool 
isConstant (Unit vs bs) = null vs 
numVariables :: Unit -4 Int 
numVariables (Unit vs _) = size vs 
powerln :: Name Type -4 Unit -4 Int 
a 'powerin' Unit vs _ = multiplicity a vs 

The dividesPowers function determines if an integer divides all the powers of 
metavariables and base units. 

dividesPowers :: Int -4 Unit -4 Bool 

n 'dividesPowers' (Unit vs bs) = dividesAII vs A dividesAII bs 
where 

dividesAII:: SignedMultiset a -4 Bool 
dividesAII = all ((0 =). (‘mod‘n). snd). toList 

The not Max function determines if the power of a variable is less than the 
power of at least one other variable. 

notMax :: (Name Type, Int) -4 Unit -4 Bool 
notMax (a, n) (Unit vs _) = any bigger (toList vs) 
where bigger (/3,m) = a ^ /3 A abs n ^ abs m 

The (©), (0) and (©) operators respectively multiply and divide units, and 
raise a unit to a constant power. 

(©) :: Unit -4 Unit -4 Unit 

Unit vs bs® Unit vs' bs = Unit (additiveUnion vs vs') (additiveUnion bs bs) 
( 0 ) :: Unit -4 Unit -4 Unit 
d 0 e = d ® invert e 
(©) :: Unit -4 Int -4 Unit 

Unit vs bs © k = Unit (multiply k vs) (multiply k bs) 
invert:: Unit -4 Unit 

invert (Unit vs bs) = Unit (shadow vs) (shadow bs) 
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The pivot function removes the given metavariable from the unit, inverts it 
and takes the quotient of its powers by the power of the removed variable. 

pivot:: Name Type —>• Unit —>• Unit 
pivot a e = invert $ quotient $ e 0 (metaUnit a © n) 
where 

n = a 'powerin' e 

quotient (Unit vs bs ) = mkUnit (map (second ( 'quot'ra)) (toList vs)) 
(map (second ( 'quot'n)) (toList bs)) 

The substUnit function substitutes a unit for a metavariable in another unit. 

substUnit:: Name Type —y Unit —>• Unit —» Unit 
substUnit a d e = ((d 0 metaUnit a) © (a 'powerin' e)) ® e 


B.2 Representation of types 

Now I extend the representation of types and contexts from Section A.l to include 
units of measure, as described in Subsection 3.0.2 (page 33). The datatype of 
types retains metavariables, variables and functions, and gains syntax for units 
(types of kind U): the identity, multiplication, constant expontentiation and base 
units. The Float constructor is an example of a type parameterised by a unit. 

data Kind =*\U 

data Type = M (Name Type) | V (Name Type) | Type -> Type 

| Float Type | One | Type : * Type | Type : A Int | Base BaseUnit 

The set of free metavariables is computed in the obvious way. 

fmv :: Type —>• Set (Name Type) 

fmv (M a) = {a} 

fmv (V a) = 0 

fmv (r -» v) — fmv r U fmv v 

fmv (Float u) — fmv v 

fmv One = 0 

fmv (u :*v') = fmv v U fmv v' 

fmv (v : A _) = fmv v 

fmv (Base _) = 0 
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It is easy to convert a semantic Unit to a syntactic expression Type, while the 
other direction may fail if the type is not well-kinded. 

unitToType :: Unit —>• Type 

unitToType (Unit xs ys) = foldr (\ a k t —>• (M a : A k) :*r) One xs 

: * foldr (\u k t —y (Base u : A k) : * r) One ys 

typeToUnit:: Type —>• Unit 

typeToUnit (M a) = metaUnit a 

typeToUnit One = mkUnit [] [] 

typeToUnit (u : * z/) — typeToUnit v © typeToUnit v' 

typeToUnit (u : A k) = typeToUnit u © k 

typeToUnit (Base b ) = mkUnit [] [( b , 1)] 

typeToUnit- = error "typeToUnit: kind error" 

Type schemes are defined as in Appendix A, except that each V quantifier 
carries a kind. 

data Scheme = T Type | All Kind (Bind (Name Type) Scheme) 

Similarly, contexts are generalised to record the kinds of metavariables: 

type Context = Bwd Entry 

type Suffix = [(Name Type, Kind, Decl Type)] 

data Entry = E (Name Type) Kind (Decl Type) 

| Z (Name Tm) Scheme 

I 9 

data Decl v = HOLE | DEFN v 

The type Tm of terms is unchanged from Appendix A. Likewise, the Contextual 
monad and popL, find and inScope operations use the new definition of Context 
but are otherwise identical. The fresh Meta operation is parameterised over the 
kind of the metavariable to create: 

freshMeta :: String —>• Kind —>• Contextual (Name Type) 
fresh Meta a k = do a <- fresh (s2n a) 

modify (:<E a k HOLE) 
return a 
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The unification algorithm must searching the context for metavariable decla¬ 
rations (perhaps of a particular kind), make some changes and either choose to 
restore the existing declaration or replace it with a new one. As before, the onTop 
function captures this pattern, and it is used to implement onTop* and onTop w 
that look for a metavariable of the corresponding kind. 

data Extension = Restore | Replace Suffix 

restore :: Contextual Extension 

restore = return Restore 

replace :: Suffix —>• Contextual Extension 

replace = return o Replace 

onTop :: (Name Type —>• Kind —>• Decl Type —>• Contextual Extension) —>• 
Contextual () 

onTop / = popL :»= \ e — > case e of 

E and^-fand »= \ m —> case m of 

Replace E —> modify (<X E) 

Restore —> modify (:<e) 

_ —>■ onTop /» modify (:<e) 

onTop* :: (Name Type —* Decl Type —» Contextual Extension) —>■ 

Contextual () 

onTop* / = onTop $ \ a k d —>• case k of 

* ->• / « d 

U —>• onTop* / » restore 

onTop w :: (Name Type —> Decl Type —> Contextual Extension) —>■ 

Contextual () 

onTop w / = onTop $ \ a k d —)• case k of 

U —>• / a. d 

★ ->■ onTop w / » restore 

B.3 Unification of unit expressions 

I now implement the abelian group unification algorithm given in Section 3.1 
(page 35). This is based around an algorithm for unifying single expressions with 
the group identity. A pair of expressions can then be unified thus: 

unifyllnit:: Type —>• Type —>• Contextual () 

unifyllnit d e — unifyld Nothing $ typeTollnit d 0 typeTollnit e 
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To unify a unit expression e with the identity, first check if it is already the identity 
(and win) or is another constant (and lose). Otherwise, search the context for 
group variables that occur in e. When one is found, either substitute it into the 
expression (if it has a definition) or examine the coefficients to determine how to 
proceed. If its coefficient n divides all the others, it can be defined to solve the 
equation. Otherwise, either reduce the coefficients modulo n or just collect the 
variable and move it back in the context. 

unifyld :: Maybe (Name Type) —>■ Unit —* Contextual () 
unifyld 3/ e 

| isldentity e = return () 

| isConstant e — throwError "Unit mismatch!" 

| otherwise = onTop w $ \ a d —>• 
let n = a 'powerin' e in 

case d of 

_ | n = 0 —>• do unifyld 3/ e 

restore 

DEFN x —» do modify (ins \P) 

let e' = substUnit a (typeToUnit x) e 

unifyld Nothing e' 

restore 

HOLE 

| n 'dividesPowers' e —>• do modify (ins \P) 

let p = pivot a e 

replace [(cr, U, DEFN (unitToType p))] 

| (a, n) 'notMax' e —> do modify (ins &) 

/3 <— fresh (s2n "beta") 
let p = pivot a e® metaUnit f3 
unifyld (Just (3) $ substUnit ape 
replace [(a, U, DEFN (unitToType p))] 

| numVariables e > 1 —>• do unifyld (Just a) e 
replace [] 

| otherwise —> throwError "No way!" 

ins :: Maybe (Name Type) —> Context —>• Context 

ins Nothing 6=6 

ins (Just a) 6 = 6 :<E aU HOLE 
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B.4 Unification of types 


Here I implement the type unification algorithm given in Section 3.2 (page 39). 
The implementation of unify for types with units of measure is very similar to the 
version in Section A.2, except that it calls unifyllnit to unify the unit annotations 
of Float types, and uses startSolve in place of solve as discussed below. 

unify :: Type —>• Type —> Contextual () 
unify (t 0 —> ly) (u 0 —> ty.) — unify t 0 v 0 » unify T\ iq 
unify (Float d) (Float e) = unifyllnit d e 
unify (M a) (M /3) = onTop* $ \ 7 d — >■ case 

(7 = a, 7 = fd, d) of 
(True, True, _ ) —* restore 

(True, False, HOLE ) replace [(a,*, DEFN (M /?))] 

(False, True, HOLE ) ->• replace [(/?,*, DEFN (M «))] 

(True, False, DEFN r) — > unify (M (5) r » restore 

(False, True, DEFN r) — >• unify (M a) r » restore 

(False, False, _ ) —> unify (M a) (M /3) » restore 

unify (M a) r = startSolve a r 

unify t (M a) = startSolve a r 

unify _ _ = throwError "Rigid-rigid mismatch" 

When starting to solve a flex-rigid constraint, one has to be careful not to ac¬ 
cidentally lose polymorphism, as explained in Subsection 3.2.1 (page 40). The 
syntactic occurs check performed by solve is not quite right, because the richer 
equational theory of abelian groups may exhibit apparent dependency when there 
is in fact none. Thus startSolve replaces units in the rigid type with fresh variables, 
solves the flex-rigid constraint first, then unifies the units. 

startSolve :: Name Type —>• Type —>■ Contextual () 
startSolve «r = do (p, xs) <— rigidHull r 

solve a (constraintsToSuffix xs) p 
solveConstraints xs 

The rigidHull operation computes the ‘hull’ of a type of kind *. replacing unit 
subexpressions with fresh variables. Along with the hull, it returns the constraints 
between the fresh variables and the units they replaced. 
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rigidHull :: Type —> Contextual (Type, [(Name Type,Type)]) 
rigidHull (M a) = return (M a, []) 

rigidHull (V a) = return (V a, []) 

rigidHull (r -> v) = do (t', xs) <— rigidHull r 
(v 1 , ys ) <— rigidHull v 
return (r' -» v\ xs © ys) 
rigidHull (Float d) = do /3 <— fresh (s2n "beta") 

return (Float (M /3), [(/3, d)]) 

A list of constraints can be turned into the appropriate context suffix by discard¬ 
ing the types and adding unit declarations for the metavariables: 

constraintsToSuffix :: [(Name Type, Type)] —>• Suffix 
constraintsToSuffix = map (\ (a, _) —>• (a,U, HOLE)) 

Or they can be solved by repeatedly invoking unifyllnit: 

solveConstraints :: [(Name Type, Type)] —> Contextual () 
solveConstraints = mapM_ (uncurry $ unifyllnit o M) 

The implementation of solve is almost identical to the version in Appendix A. 

solve :: Name Type —> Suffix —> Type —> Contextual () 
solve a S r = onTop* $ 

\ 7 d ->• case 


(7 = « 

, 7 e fmv t, d 

) of 



DEFN 

v) — y modify (<X S) 

» unify (subst 7 v (M «)) (subst 7 v t) 

» restore 

(True, 

True, 

HOLE 

) —>• throwError "Occurrence detected! 

(True, 

False, 

HOLE 

) —> replace $ E O [(a,*, DEFN r)] 

(False, 

True, 

HOLE 

) —>• solve a (( 7 ,*, HOLE) : E) r 

» replace [] 

(False, 

False, 

HOLE 

) — y solve a E t 


» restore 


213 



Appendix C 

Reference implementation of 
Miller pattern unification 


Having specified the pattern unification algorithm in Chapter 4, I now implement 
it in Haskell. The code is organised along similar lines to the previous two appen¬ 
dices, although the details differ substantially. First I describe the representation 
of object language terms (Section C.l) and the domain-specific language in which 
I will implement the algorithm (Section C.2). I then give implementations of type 
and equality checking (Section C.3), and unification (Section C.4). 


C.l Representation of terms 

First I define terms and machinery for working with them (including evaluation 
and occurrence checking), based on the description in Subsection 4.1.1 (page 53). 

Object language terms are represented using the data type Tm. The Binders 
Unbound library of Weirich et al. (2011b) defines the Bind type constructor 
and gives a cheap locally nameless representation with operations including a- 
equivalence and substitution for first-order datatypes containing terms. I use a 
single constructor for all the canonical forms (that do not involve binding) so as 
to factor out common patterns in the typechecker. 

data Tm where 

A :: Bind Nom Tm — > Tm 
:: Head —>• Bwd Elim Tm 
C :: Can Tm —>• Tm 
n, E :: Type —> Bind Nom Type Tm 


type Nom = Name Tm 





data Can t — Set Type | Pair 11 | Bool | Tt | Ff | N | Ze | Su t 

data Head = V Nom Twin | M Nom 

data Twin = Only | TwinL | TwinR 

data Elim = A Tm | Hd | Tl | If (Bind Nom Type) Tm Tm 

type Type = Tm 

The non-binding canonical forms Can induce a Foldable functor (which can be 
derived automatically by GHC). Annoyingly, Elim cannot be made a functor in 
the same way, because Bind Nom is not a functor on * but only on the subcategory 
induced by Alpha. However, the action on morphisms can be defined thus: 

mapElim :: (Tm —>■ Tm) —>• Elim Elim 
mapElim / (A a) = A (/ a) 
mapElim _ Hd = Hd 

mapElim _ Tl = Tl 

mapElim / (If T h t) - If (bind x (/ T')) (/ 5 ) (/ t) 

where (x, T') = unsafellnbind T 
fold MapElim :: Monoid m =>• (Tm —> m) —>• Elim —> m 
foldMapElim / (A a) =fa 

foldMapElim Hd = mempty 

foldMapElim _ Tl = mempty 

foldMapElim / (If T s t) = f V 0/ 5 ©/ t 

where (_, T') = unsafellnbind T 

Despite the single-constructor representation of canonical forms, it is often 
neater to write code as if Tm had a data constructor for each canonical constructor 
of the object language. This is possible thanks to pattern synonyms (Aitken and 
Reppy, 1992) as implemented by the Strathclyde Haskell Enhancement (McBride, 
2010b). Pattern synonyms are abbreviations that can be used ‘on the left’ (in 
patterns) as well as ‘on the right’ (in expressions). 


pattern Type 

= C Type 

pattern Set 

= CSet 

pattern pair s 1 

t = C (Pair 5 t) 

pattern B 

= C Bool 

pattern tt 

= CTt 

pattern ff 

= C Ff 

pattern N 

= CN 

pattern ze 

= C Ze 

pattern su n 

= C (Su n) 
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Free variables 


Rather than definining functions to determine the free metavariables and variables 
of terms directly, I use a typeclass to make them available on the whole syntax. 

data Flavour = Vars | RigVars | Metas 
class Occurs t where 
free :: Flavour —>■/—>■ Set Nom 

fv, fv ng , fmv :: Occurs t =>• t —> Set Nom 
fv = free Vars 
fv rig = free RigVars 
fmv = free Metas 

instance Occurs Tm where 
free / (A b) = free l b 

free / (C c) = free l c 

free l(n5T) = free l S U free l T 

free l (E S T) = free l S U free l T 

free RigVars (V x _ • e) = {x} U free RigVars e 
free RigVars (M _ • _) =0 
free l (h ■ e) = free l h U free l e 

instance Occurs t Occurs (Can t) where 
free l (Pair s t) = free / s U free 11 
free / (Sun) = free / n 

free l =0 

instance Occurs Head where 
free Vars (M _) =0 
free RigVars (M _) =0 
free Metas (M a) = {«} 
free Vars (V x _) = {x} 
free RigVars (V x __) = {x} 

free Metas (V_) = 0 

instance Occurs Elim where 
free l (A a) = free l a 

free / Hd =0 

free l Tl =0 

free l (If T s t) = free l T U free l s U free /1 
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Evaluation by hereditary substitution 

Substitutions are implemented as finite maps from names to terms; as a technical 
convenience there is no distinction between substitution and metasubstitution. 

type Subs = [(Nom, Tm)] 

(o) :: Subs —* Subs ->• Subs 

S' o 8 = unionBy ((=) ‘on‘ fst) S' (substs S' 8) 

The evaluator is an implementation of hereditary substitution defined in Fig¬ 
ure 4.2 (page 54): it proceeds structurally through terms, replacing variables 
with their values and eliminating redexes using the ( %%) operator defined below. 

eval :: Subs —> Tm —>• Tm 

eval g (X b) = A (evalUnder g b) 

eval g (h ■ e) = foldl (%%) (evalHead g h ) (fmap (mapElim (eval g)) e ) 
eval g (C c) = C (fmap (eval g) c) 
eval g (n S T) = II (eval g S ) (evalUnder g T) 
eval g (E S T) = E (eval g S) (evalUnder g T) 
evalHead :: Subs —> Head -^Tm 
evalHead g (V x _) | Just t <— lookup x g = t 
evalHead g (M a) \ Just t <— lookup a g = t 
evalHead g h — h ■ • 

evalUnder:: Subs —> Bind Nom Tm ^ Bind Nom Tm 
evalUnder g b = bind x (eval g t) 
where (x, t ) = unsafeUnbind b 

The (%%) operator reduces a redex (a term with an eliminator) to normal form: 
this re-invokes hereditary substitution when a A-abstraction meets an application. 

(%%) ::Tm-> Elim —y Tm 

A b %% (A a) = eval [(x, a)] t where (x, t) = unsafeUnbind b 

pairx_%%Hd —x 

pair _ y %% Tl = y 

tt %% If _ t - = t 

ff %%lf __/ = / 

h ■ e %%z — h • (e :< z) 

t %%a = error "bad elimination" 
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I define some convenient abbreviations: ($$) for applying a function to an 
argument, ($*$) for applying a function to a telescope of arguments, •{•} for 
substituting out a single binding and hd and tl for the projections from E-types. 

($$)::Tm—>• Tm —>Tm 
/ $$ a = f %% A a 

($*$):: Tm —>■ Bwd (Nom, Type) -^Tm 
/$*$T = foldl ($$) / (fmap (var. fst) r) 

■ {•} :: Bind Nom Tm -)• Tm —>■ Tm 
/{•*>} = A fns 
hd, tl :: Tm —>• Tm 
hd « (%% Hd) 
tl = (%%TI) 

C.2 Problems and contexts 

I will now define unification problems, metacontexts and operations for working 
on them in the Contextual monad. The notions of metacontext and context in use 
were given in Subsection 4.1.2 (page 55), and the monadic approach develops that 
of the previous appendices. Metacontext entries now consist of metavariables, as 
before, or problems, which carry a status bit used to record whether they have 
been solve as far as possible given their current type (see Subsection C.4.6). 
Problems are equations under universally quantified parameters, and parameters 
may include twins. 

data Decl v = HOLE | DEFN v 

data Entry = E (Name Tm) (Type, Decl Tm) | Q Status Problem 

data Status = Blocked | Active 

data Param = P Type | TypeJType 

type Params = Bwd (Nom, Param) 

data Equation = (Tm : Type) « (Tm : Type) 

data Problem = Unify Equation | All Param (Bind Nom Problem) 

The sym function swaps the two sides of an equation: 

sym :: Equation —>• Equation 

sym ((s : S) M (t : T)) = (t : T) « (s : S) 
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The metacontext is represented as a list zipper: a pair of lists representing 
the entries before and after the cursor. Entries after the cursor may include 
substitutions, being propagated lazily. 

type ContextL = Bwd Entry 

type ContextR = [Either Subs Entry] 

type Context = (ContextL, ContextR) 

The Contextual monad stores the current context and parameters, generates 
fresh names when required for going under binders, and handles exceptions. 

newtype Contextual a = Contextual 

(ReaderT Params (StateT Context (FreshMT (ErrorT String Identity))) a) 


Reading and modifying state 

I define versions of the usual state-manipulating get, modify and put operations 
that act on the left or right part of the context (before or after the cursor). 

getL :: Contextual ContextL 
getL = gets fst 
getR:: Contextual ContextR 
getR = gets snd 

modifyL :: (ContextL —>■ ContextL) —* Contextual () 
modifyL = modify o first 

modifyR :: (ContextR —>■ ContextR) —>■ Contextual () 

modifyR = modify o second 

putL :: ContextL —>• Contextual () 

putL = modifyL o const 

putR :: ContextR —> Contextual () 

putR = modifyR o const 

Here are operations to push to, or pop from, either side of the cursor, or move 
the cursor one entry to the left: 

pushL :: Entry —>• Contextual () 

pushL e — modifyL (:<e) 

pushR :: Either Subs Entry —y Contextual () 

pushR e = modifyR (e:) 
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pushLs :: Traversable f => f Entry —>■ Contextual () 
pushLs es — traverse pushL es return () 
popL :: Contextual Entry 
popL = do 0 4 — getL 

case 0 of (O' :< e) —>■ putL 0' » return e 

• —y throwError "popL: out of context" 

popR :: Contextual (Either Subs Entry) 
popR = do 0 i- getR 

case 0 of (x : 0') —* putR 0' » return x 

I —>• throwError "popR: out of context" 

goLeft:: Contextual () 

goLeft = popL »= pushR o Right 

Variable and metavariable lookup 

The context of local parameters is tracked using the ReaderT monad transformer, 
so the local operation can be used to bring a parameter into scope, and the ask 
operation can be used to look up a variable. 

inScope :: Nom —» Param —* Contextual a —* Contextual a 
inScope x p = local (:<(x,p)) 
lookupVar:: Nom —>• Twin —» Contextual Type 
lookupVar x w = help w ask 
where 

help Only (T :< (y, P T)) | x = y — return T 

help TwinL (T :< (y, S\T)) \ x = y — return S 

help TwinR (T :< (y, S^T)) \ x = y — return T 

help w (/’ :<. ) = help w T 

help _ • = throwError $ "lookupVar : missing " -H- show x 

The type of a metavariable can be determined from its name by searching the 
metacontext. Only metavariables left of the cursor are in scope. 

lookupMeta :: Nom —> Contextual Type 
lookupMeta x = look getL 
where 

look (0 :< E y (T, _)) | x = y — return T 

look (0 :< _) = look 0 

look • = error $ "lookupMeta: missing " -H- show x 
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C.3 Type and equality checking 


Here I give a typechecker and definitional equality test for the type theory defined 
in Subsection 4.1.3 (page 56). With the Contextual monad operations, 1 define 
a bidirectional typechecker, based on a typed definitional equality test between 
/35-normal forms that produces an 77 -long standard form. The equalise T s t 
function implements the judgment 0 | T b T 3 s ^ n ]= 1 , defined in Figure 4.4 
(page 59), where u is the result. 

equalise :: Type —> Tm —> Tm —> Contextual Tm 
equalise Type Set Set = return Set 

equalise Type S T = equalise Set S T 

equalise Set B B = return B 

equalise B tt tt = return tt 

equaliseB ff ff = return ff 

equalise Set (n A B) (n S T) = do 
U equalise Set A S 
n U ($) bindsInScope U B T 

(\x B' V —y equalise Set B' T') 
equalise (U U V) f g = 

A ($) bindInScope U V 

(\x V' —y equalise V' (/var x) (guvarx)) 
equalise Set (E A B) (E S T) = do 
U t— equalise Set A S 
E f/($) bindsInScope UBT 

(\x B' V —>■ equalise Set B' T') 
equalise (E U V) s t = do 
uq t— equalise U (hd s) (hd t) 
ui t— equalise (F{?xo}) (tl s ) (tl t) 
return (pair v<) 

equalise U (h ■ e) (h' ■ e') = do 
(h", e", V) t— equaliseN h eh' e' 
equalise Type U V 
return {h" ■ e") 

Similarly, the equaliseN h e hi el function implements the equality judgment 
0 | T h h ■ e ^ h" ■ e" ^ h' ■ e' & T, defined in Figure 4.5 (page 60), where h", e” 
and T are the results. 
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equaliseN :: Head —* Bwd Elim —* Head —* Bwd Elim —y 
Contextual (Head, Bwd Elim, Type) 
equaliseN h • h! • \ h = h! — (h, •,) ($) infer h 

equaliseN h (e:< A 5) h! (ef :< A t) = do 
(h", e", n U V) <- equaliseN h e h! e' 
u equalise U s t 

return (h", e" :< A u, V{u}) 
equaliseN h (e :< Hd) h! (e' :< Hd) = do 
(h", e", E U V) <r- equaliseN h eh! e' 
return (h", e" :< Hd, U) 
equaliseN h (e :< Tl) h' (e' :< Tl) = do 
(h", e", E U V) <r- equaliseN h eh' e' 
return (h", e" :< Tl, V{h" ■ (e" :< Hd)}) 
equaliseN h (e :< If T u v ) h' (e' :< If T' v! v') — do 
(h", e",B) <r- equaliseN h eh' e' 

U" <- bindsInScope B T T (\ x U U' equalise Type U U') 

u" <r- equalise (U"{ tt}) u u' 

v" 4 - equalise (C/"{fF}) v v' 

return (h", e" :< If U" u" v", U"{h" ■ e"}) 

The infer function looks up the type of a head, using lookupVar or lookupMeta 
from the previous section as appropriate. 

infer:: Head —> Contextual Type 
infer (V x w) = lookupVar x w 
infer (M x) = lookupMeta x 

The bindInScope and bindsInScope helper operations introduce a binding or two 
and call the continuation with a variable of the given type in scope. 

bindlnScope :: Type —>• Bind Nom Tm —> 

(Nom —> Tm —* Contextual Tm) —> 

Contextual (Bind Nom Tm) 
bindlnScope T b f = do (x, b') <— unbind b 

bind x ($) inScope x (P T ) (/ x b') 
bindsInScope :: Type —>• Bind Nom Tm Bind Nom Tm —> 

(Nom —>• Tm —>• Tm —>• Contextual Tm) ^ 

Contextual (Bind Nom Tm) 

bindsInScope T a b f = do Just (x, a', , b') <— unbind2 a b 

bind x ($) inScope x (P T) (/ x a' b') 


222 



Equality checking can return a Boolean instead of throwing an error when the 
terms are not equal. Since typing is the diagonal of equality, it is easy to define 
a typechecking function as well. 

equal:: Type —> Tm —> Tm —> Contextual Bool 

equal T s t = (equalise T s t^> return True) ® (return False) 

typecheck :: Type —)■ Tm —)■ Contextual Bool 

typecheck T t = equal T t t 

Finally, a convenience function that tests if a heterogeneous equation is re¬ 
flexive, by checking that the types are equal and the terms are equal. 

isReflexive :: Equation —> Contextual Bool 

isReflexive ((5 : S) « (t : T)) — optional (equalise Type S T ) »= 

maybe (return False) (\ U —>• equal U s t) 


C.4 Unification 

With the preliminaries out of the way, I can now present the pattern unification 
algorithm as specified in Section 4.2 (page 67). I begin with utilities for working 
with metavariables and problems, then give the implementations of inversion, 
intersection, pruning, metavariable simplification and problem simplification. Fi¬ 
nally, I show how the order of constraint solving is managed. 

Making and filling holes 

A telescope is a list of binding names and their types. Any type can be viewed 
as consisting of a Il-bound telescope followed by a non-II-type. 

type Telescope = Bwd (Nom,Type) 
telescope :: Type —* Contextual (Telescope, Type) 
telescope (II S T) = do (x, T') <- unbind T 

(A, U ) t- telescope T' 
return ((• :< (x, S)) O A, U) 
telescope T = return (•, T) 

The hole control operator creates a metavariable of the given type (under a tele¬ 
scope of parameters), and calls the continuation with the metavariable in scope. 
Finally, it moves the cursor back to the left of the metavariable, so it will be 
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examined again in case further progress can be made on it. The continuation 
must not move the cursor. 


hole :: Telescope —>• Type —>• (Tm —>• Contextual a) — > Contextual a 
hole r T f = do a <- fresh (s2n "alpha") 

pushLSEo; (nr. T, HOLE) 
r <— f (meta a $*$ T) 
go Left 
return r 

Once a solution for a metavariable is found, the define function adds a defi¬ 
nition to the context. (The declaration of the metavariable should already have 
been removed.) This also propagates a substitution that replaces the metavari¬ 
able with its value. 

define :: Telescope —>■ Nom ->• Type ->■ Tm ->• Contextual () 
define r a S v = do pushR $ Left [(«, t)] 

pushRS RightS E a (T,DEFN t) 
where T — nr. S 
t = Ar. v 


Postponing problems 

When a problem cannot be solved immediately, it can be postponed by adding 
it to the metacontext. The postpone functions wraps a problem in the current 
context (as returned by ask) and stores it in the metacontext with the given 
status. The active function postpones a problem on which progress can be made, 
while the block function postpones a problem that cannot make progress until its 
type becomes more informative, as discussed in Subsection C.4.6. 

postpone :: Status —>• Problem —y Contextual () 
postpone s p = pushR o Right oQ so wrapProb p ask 
where 

wrapProb :: Problem —>• Params —>• Problem 
wrapProb = foldr (\ (x, e) p —> All e (bind x p)) 
active, block :: Problem —y Contextual () 
active = postpone Active 
block = postpone Blocked 
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A useful combinator 


The following combinator executes its first argument, and if this returns False 
then it also executes its second argument. 

(©) :: Monad m =>• m Bool —> m () —> m () 
a® b = do a; •<— a 

unless x b 


C.4.1 Inversion 

A flexible unification problem is one where one side is an applied metavariable 
and the other is an arbitrary term. The algorithm moves left in the context, 
accumulating a list of metavariables S that the term depends on, to construct 
the necessary dependency-respecting permutation. Once the target metavariable 
is reached, it can attempt to find a solution by inversion. This implements step 
(4.16) in Figure 4.15 (page 80), as described in Subsection 4.2.1 (page 67). 

flexTerm :: [Entry] —>• Equation —>• Contextual () 
flexTerm E q@( M a ■ _ ps _) = do 
r -ir- fmap snd ($) ask 
popL »= \ e —>• case e of 
E /3 (T, HOLE) 

| a = /3 A a G fmv E — > do pushLs (e : _ Xi) 

block (Unify q) 

| a = /3 > do pushLs E 

trylnvert q T 

© (block (Unify q) » pushL e) 

| f} e fmv (r, E, q) flexTerm (e: E) q 
->• do pushR (Right e) 
flexTerm E q 

A flex-flex unification problem is one where both sides are applied metavari¬ 
ables. As in the general case above, the algorithm proceeds leftwards through the 
context, looking for one of the metavariables so it can try to solve one with the 
other. If it reaches one of the metavariables and cannot solve for the metavariable 
by inversion, it continues (using flexTerm), which ensures it will terminate after 
trying to solve for both. For example, consider the case ati « /3x] j where only 
Xji is a list of variables. If it reaches a first then it might get stuck even if it 
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could potentially solve for /3. This would be correct if order were important in 
the metacontext, for example when implementing let-generalisation as discussed 
in Chapter 2. Here it is not, so the algorithm can simply pick up a and carry on. 

flexFIex :: [Entry] —* Equation —* Contextual () 
flexFIex 3 q @(M a ■ ds m M /? • es) — do 

r 4- fmap snd ($) ask 
popL »= \ e -4 case e of 
E 7 (T, FIOLE) 

| 7 G [a, /?] A 7 G fmv (H) -4 do pushLs (e : 3) 
block (Unify q ) 

| 7 = a —> do pushLs 3 

trylnvert q T © flexTerm [e] (sym q) 

| 7 = [3 -4 do pushLs 3 

trylnvert (sym q) T ©flexTerm [e] q 
| 7 e fmv (r, H, g) -4 flexFIex (e : S’) 

-4 do pushR (Right e) 
flexFIex 3 q 

Given a flexible equation whose head metavariable has just been found in 
the context, the trylnvert control operator calls invert to seek a solution to the 
equation. If it finds one, it defines the metavariable. 

trylnvert:: Equation -4 Type -4 Contextual Bool 
trylnvert g@(M a ■ e « s) T — invert a T e s »= \ m —> case m of 
Nothing -4 return False 
Just v -4 do active (Unify q) 
define • a T v 
return True 

Given a metavariable a of type T, spine e and term f, invert attempts to find 
a value for a that solves the equation « • e ~ t. It will throw an error if the 
problem is unsolvable due to an impossible occurrence. 

invert:: Norn -4 Type -4 Bwd Elim —> Tm —> Contextual (Maybe Tm) 
invert a T e t \ occurCheck True at = throwError "occur check" 

| a £ fmv t, Just xs 4- toVars e, linearOn t xs = do 
b 4- local (const •) (typecheck T (A xs. t )) 
return $ if b then Just (Azs. t) else Nothing 
| otherwise = return Nothing 
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Note that the solution A xs. t is typechecked under no parameters, so typechecking 
will fail if an out-of-scope variable is used. 

The occur check, used to tell if an equation is definitely unsolvable, looks for 
occurrences of a metavariable inside a term. In a strong rigid context (where the 
first argument is True), any occurrence is fatal. In a weak rigid context (where it 
is False), the evaluation context of the metavariable must be a list of variables. 

occurCheck:: Bool —>■ Nom —> Tm —> Bool 
occurCheck w a (A b) = occurCheck w at 

where (_, t) = unsafeUnbind b 

occurCheck w a (V_ • e) getAny $ foldMap 

(foldMapElim (Any o occurCheck False a)) e 
occurCheck w a (M ,3 ■ e) = a = (3 A (w V isJust (toVars e)) 
occurCheck w a (C c) = getAny $ foldMap (Any o occurCheck w a) c 
occurCheck w a (II S T) = occurCheck w a S V occurCheck w a V 
where (_, T') = unsafeUnbind T 

occurCheck w a (E S T) = occurCheck w a S V occurCheck w a V 
where (_, T') = unsafeUnbind T 

Here toVars tries to convert a spine to a list of variables, and linearOn determines 
if a list of variables is linear on the free variables of a term. Since it is enough 
for a term in a spine to be r )-convertible to a variable, the etaContract function 
implements ^-contraction for terms. 

linearOn :: Tm —> Bwd Nom —> Bool 
linearOn • = True 

linearOn t (as :< a) = -> (a e fv t A a e as) A linearOn t as 


etaContract:: Tm -)• Tm 

etaContract (A b ) = case etaContract t of 

x ■ (e :< A (V y' _ • •)) | y = y', (y e fv e) -)• x ■ e 

f —> A y. t' 

where (y, t ) = unsafeUnbind b 
etaContract (x- as) — x ■ (fmap (mapElim etaContract) as) 
etaContract (pair s t) — case (etaContract s, etaContract t) of 
(x ■ (as :< Hd), y ■ (bs :< Tl)) | x = y, as = bs —> x ■ as 
(s', t') —y pair s' t' 

etaContract (C c) = C (fmap etaContract c) 
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toVar:: Tm —> Maybe Nom 

toVar v — case etaContract v of V x _ • • —>• Just x 
—y Nothing 

toVars :: Traversable f => f Elim —>• Maybe (/ Nom) 
toVars = traverse (unA >=> toVar) 
where unA (A t) = Just t 
unA = Nothing 

C.4.2 Intersection 

When a flex-flex equation has the same metavariable on both sides, i.e. it has 
the form a of 1 ~ a~y~i l where xl l and Iff are both lists of variables, the equation 
can be solved by restricting a to the arguments on which x~f and If 1 agree (i.e. 
creating a new metavariable f3 and using it to solve a). This implements step 
(4.18) in Figure 4.15 (page 80), as described in Subsection 4.2.2 (page 70). 

The flexFIexSame function extracts the type of a as a telescope and calls 
intersect to generate a restricted telescope. If this succeeds, it calls instantiate to 
create a new metavariable and solve the old one. Otherwise, it leaves the equation 
in the context. Twin annotations can be ignored here here because any twins will 
have definitionally equal types anyway. 

flexFIexSame :: Equation —>• Contextual () 
flexFIexSame g@(M a ■ e ~ M a ■ e') = do 
(A, T ) <r- telescope lookupMeta a 
case intersect A e e' of 

Just A' | fv T c vars A 1 —> instantiate (a, HA'. T, \0 —> XA./3$*$A) 

—>• block (Unify q ) 

Given a telescope and the two evaluation contexts, intersect checks the evaluation 
contexts are lists of variables and produces the telescope on which they agree. 

intersect:: Telescope —> Bwd Elim -4 Bwd Elim -4 Maybe Telescope 
intersect • • • = return • 

intersect (A :< (z, S)) (e :< A s) (e' :< A /.) — do 
A' 4- intersect A e e' 
x <— toVar s 
y <- toVar t 

if x = y then return ( A' :< (z, S)) else return A' 
intersect_= Nothing 
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C.4.3 Pruning 

Given a flex-rigid or flex-flex equation, it might be possible to make some progress 
by pruning the metavariables contained within it, as described in Subsection 4.2.3 
(page 71). The tryPrune function calls pruneTm: if it learns anything from prun¬ 
ing, it leaves the current problem active and instantiates the pruned metavariable. 

tryPrune :: Equation —» Contextual Bool 

tryPrune g@(M a ■ e « t) = pruneTm (fv e) t »= \ u —>• case u of 
d : _ —>• active (Unify q) » instantiate d » return True 

; j —>• return False 

Pruning a term requires traversing it looking for occurrences of forbidden 
variables. If any occur rigidly, the corresponding constraint is impossible. If 
a metavariable is encountered, it cannot depend on any arguments that contain 
rigid occurrences of forbidden variables, so it can be replaced by a fresh metavari¬ 
able of restricted type. The pruneTm function generates a list of triples (/3, U,f) 
where f3 is a metavariable, U is a type for a new metavariable 7 and / 7 is 
a solution for ft. It maintains the invariant that U and / 7 depend only on 
metavariables defined prior to (3 in the context. 

pruneTm :: Set Norn —>• Tm —> Contextual [Instantiation] 
pruneTm V (II S’ T) = (df) ($) pruneTm V S (*) pruneUnder V T 

pruneTm V (E S T) = (df) ($) pruneTm V S (*) pruneUnder V T 

pruneTm V (pair s t) — (-H-) ($) pruneTm V s (*) pruneTm V t 

pruneTm V (A b) = pruneUnder V b 

pruneTm V (M (3 ■ e) = pruneMeta V /? e 

pruneTm V (C _) = return [] 

pruneT mV(V^_-e)|^eV = pruneElims V e 

| otherwise = throwError "pruning error" 
pruneUnder:: Set Norn —y Bind Norn Tm Contextual [Instantiation] 
pruneUnder V b = do (x, t) <— unbind b 

pruneTm (V U {x}) t 

pruneElims :: Set Norn —>■ Bwd Elim —)■ Contextual [Instantiation] 
pruneElims V e = fold ($) traverse pruneElim e 
where 

pruneElim (A a ) = pruneTm V a 

pruneElim (If T s t) = (df) ($) ((df) ($) pruneTm V s (*) pruneTm V t) 

(*) pruneUnder V T 

pruneElim _ = return [] 
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Once a metavariable has been found, pruneMeta unfolds its type as a telescope 
IIA T, and calls prune with the telescope and list of arguments. If the telescope 
is successfully pruned (A is not the same as A) and the free variables of T remain 
in the telescope, then an instantiation of the metavariable is generated. 

pruneMeta :: Set Nom —>• Nom —y Bwd Elim —>• Contextual [Instantiation] 
pruneMeta V 0 e — do 
(A, T ) telescope lookupMeta 0 
case prune V A e of 
Just A' | A' ± A, fv T c vars A' 

—» return [(0, n A'. T, \ beta' —» XA. beta' $*$ A')] 

—>■ return [] 

The prune function generates a restricted telescope, removing arguments that 
contain a rigid occurrence of a forbidden variable. This may fail if it is not clear 
which arguments must be removed. 

prune :: Set Nom —>• Telescope —>■ Bwd Elim —>• Maybe Telescope 
prune V • • = Just • 

prune V (A :< (x, S)) (e :< A s) — do 
A! <— prune V A e 
case toVar s of 

Just y | y e V,fv S C vars A' —>■ Just (A :< (x,S)) 

| fv r| s s <(. V ->• Just A 1 

| otherwise —> Nothing 

prune_= Nothing 

A metavariable a can be instantiated to a more specific type by moving left 
through the context until it is found, creating a new metavariable and solving for 
a. The type must not depend on any metavariables defined after a. 

type Instantiation = (Nom, Type, Tm —> Tm) 

instantiate :: Instantiation —>■ Contextual () 
instantiate d@(a, T,f) = popL »= \ e —> case e of 
E 0 ( U, HOLE) \a = 0^ hole • T (\ t ->• define • 0 U (/ t)) 

->• do pushR (Right e) 
instantiate d 
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C.4.4 Metavariable simplification 

Given the name and type of a metavariable, lower attempts to simplify it by 
removing E-types, according to the metavariable simplification steps (4.21) and 
(4.22) in Figure 4.15 (page 80), as described in Subsection 4.2.4 (page 74). 

lower:: Telescope —> Nom —>• Type —>• Contextual Bool 

lower $ a (E S T) = hole $ S $ \ 5 

hole $ (T{s})$\t —► 

define 0 a (E S T) (pair si) > 

return True 

lower 0 a (II S T) — do x <— fresh (s2n "x") 

splitSig • x S »= maybe 

(lower ($ :< (x, S)) a (T{var x})) 

(\ (y, A, z, B , s, (u , v)) —)• 
hole $ (Uy :A.Uz: B. T{s}) $ \ w -)• 
define 0 a (II S T) (Ax. w $$ u $$ v) » 
return True) 

lower 0 a T = return False 

Lowering a metavariable needs to split E-types (possibly underneath a bunch 
of parameters) into their components. For example, y:Ux:X.T,z:S. T splits into 
2 /o : IIx: X. S and y\: Tlx: X. T{y 0 x}. Given the name of a variable and its type, 
splitSig attempts to split it, returning fresh variables for the two components of 
the E-type, an inhabitant of the original type in terms of the new variables and 
inhabitants of the new types by projecting the original variable. 

splitSig :: Telescope ->• Nom Type ->• 

Contextual (Maybe (Nom, Type, Nom, Type, Tm, (Tm, Tm))) 

splitSig 0 x (E S T) = do y fresh (s2n "y") 
z <- fresh (s2n "z") 

return $ Just (y, U0. S , 2 ,11$. (T{var y $*$ $}), 

A 0. pair (var y $*$ $) (var z $*$ 0 ), 
(X0. var x$*$ 0 %% Hd, 

\0. var x$*$ $%%TI)) 

splitSig 0 x (II A B) = do a <- fresh (s2n "a") 

splitSig (0 :< (a, 4)) x (f?{var a}) 

splitSig_= return Nothing 
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C.4.5 Problem simplification and unification 

Given a problem, the solver simplifies it according to the rules in Figure 4.14 
(page 79), introduces parameters and calls unify defined below if it is not already 
reflexive. In particular, problem simplification removes E-types from parameters, 
potentially eliminating projections, and replaces twins whose types are defini- 
tionally equal with a single parameter. This implements the steps described in 
Subsection 4.2.5 (page 75). 

solver:: Problem —> Contextual () 
solver (Unify q) = do b t— isReflexive q 
unless b (unify q) 

solver (All p b) = do 
(x, q) <— unbind b 

case p of 

_ | x ^ fv q —>■ active q 
P S —>• splitSig • x S »= \ nn —* case m of 

Just (y, A, z, B , s, _) —>• solver (Vy: A Vz: B. subst x s q) 

Nothing —> inScope x (P S) $ solver q 

StT ->• equal Set S T »= \ c ->■ 

if c then solver (Vx: S. subst x (var x) q) 
else inScope x (StT) $ solver q 

The unify function performs a single unification step: 77 -expanding elements of 
II or E types via the problem simplification steps (4.2) and (4.3) in Figure 4.14 
(page 79), or invoking an auxiliary function in order to make progress. 

unify :: Equation —>■ Contextual () 
unify ((/ : II A B) « (g : II S T)) = do 
x •<— fresh (s 2 n "x") 

active $ Vx: A$S. (fnx : B{x }) « (g $$ x : T{x}) 
unify ((t: E A B) « (w : E C D)) = do 
active $ (hd t : A) « (hd w : C) 
active $ (tl t : i?{hd t}) (tl w : D {hd w}) 
unify q @(M a ■ e « M /3 ■ e') 

| a = (3 — tryPrune q © tryPrune (sym q) © flexFIexSame q 
unify g@(M a ■ e m M (3 ■ e') = tryPrune q © tryPrune (sym q) © flexFIex [] q 

unify #@(M a ■ e « t) = tryPrune q © flexTerm [] q 

unify q@(t « M a ■ e) = tryPrune (sym q) © flexTerm [] (sym q) 

unify q = rigidRigid q 
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A rigid-rigid equation (between two non-metavariable terms) can either be de¬ 
composed into simpler equations or it is impossible to solve. For example, 
II x : A. B fa II x : S. T splits into A fa S, B a T, but Ux : A. B fa E x : S.T 
cannot be solved. The rigidRigid function implements steps (4.4)-(4.7) from Fig¬ 
ure 4.14 (page 79), as described in Subsection 4.2.5 (page 75). Both unify and 
rigidRigid will be called only when the equation is not already reflexive. 

rigidRigid :: Equation —» Contextual () 
rigidRigid ((II A B : Set) » (II ST: Set)) = do 
x t— fresh (s2n "x") 
active $ (A : Set) fa- (S : Set) 
active $Vx:AtS. ( B{x} : Set) s* (T{h} : Set) 
rigidRigid ((E A B : Set) « (E ST: Set)) = do 
x <— fresh (s2n "x") 
active $ (A : Set) fa (S : Set) 
active $ V£: Af#. (B{x} : Set) fa (T{x} : Set) 
rigidRigid (V x w ■ e fa V x' w' ■ e') = 
matchSpine x w e x' w' e' » return () 
rigidRigid q \ orthogonal q = throwError "Rigid-rigid mismatch" 

| otherwise = block $ Unify q 

A constraint has no solutions if it equates two orthogonal terms, with different 
constructors or variables, as defined in Figure 4.13 (page 76). 

orthogonal:: Equation —> Bool 

orthogonal ((II_: Set) « (E_: Set)) = True 

orthogonal ((II_: Set) ~ (B : Set)) = True 

orthogonal ((E_: Set) fa (II_: Set)) = True 

orthogonal ((E_: Set) fs (B : Set)) = True 

orthogonal ((B : Set) fa (II_: Set)) = True 

orthogonal ((B : Set) fa (E_: Set)) = True 

orthogonal ((tt : B) fa (ff : B)) = True 

orthogonal ((ff : B) ta (tt : B)) = True 

orthogonal ((II_: Set) fa (V _ •_:_))= True 

orthogonal ((E_: Set) fa (V_ •_:_))= True 

orthogonal ((B : Set) fa (V _ _ • _ : _)) = True 

orthogonal ((tt : B) fa (V_ •_:_)) = True 

orthogonal ((ff : B) fa (V_ •_:_)) = True 
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orthogonal ((V (n : Set)) = True 

orthogonal ((V_•_:_)« (E_: Set)) = True 

orthogonal ((V « (B : Set)) = True 

orthogonal ((V _ •_:_)« (tt : B)) = True 

orthogonal ((V_•_:_)« (ff : B)) = True 

orthogonal _ = False 


When there are rigid variables at the heads on both sides, proceed through 
the evaluation contexts, demanding that projections are identical and unifying 
terms in applications. Note that matchSpine returns the types of the two sides, 
used when unifying applications to determine the types of the arguments. For 
example, if y:Hx:S. T{x] —Y U then the constraint y s t ~ yuv will decompose 
into (s: S) (u: S) A (£: T{s}) ps (v: T{u}). 

matchSpine :: Nom —y Twin —>• Bwd Elim —>• 

Nom —> Twin —> Bwd Elim —> 

Contextual (Type, Type) 
matchSpine x w • x' w' • 

| x = x' = (,)($) lookupVar x w (*) lookupVar x' w' 

| otherwise = throwError "rigid head mismatch" 
matchSpine x w (e :< A a) x' w' ( e' :< A s) = do 
(nAB,n5 T) <- matchSpine x w e x' w' e' 
active $ (a : A) & (s : S) 
return ( B{a }, T{s }) 

matchSpine x w (e :< Hd) x' w' (e' :< Hd) = do 
(E A B, E S T) <- matchSpine x w e x' w' e 1 
return (A, S) 

matchSpine x w (e :< Tl) x' w' (e ' :< Tl) = do 
(E A B, E S T) <- matchSpine x w e x' w' e' 
return (5{V x w ■ (e :< Hd)}, T{V x' w' ■ (e' :< Hd)}) 
matchSpine x w (e :< If T s t) x' w' (e' :< If V s' t') = do 
(B,B) ■<— matchSpine x w e x' w' e' 
y 4- fresh (s2n "y") 

active $ V?/:B. (T{var y} : Type) m (T'{var y} : Type) 
active $ (s : T{tt}) w (s' : T'jtt}) 
active $ [t : T{fF}) ps {t' : T'{fF}) 
return (T{V x w - e}, T'{V x' w' ■ e'}) 

matchSpine_= throwError "spine mismatch" 
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C.4.6 Solvitur ambulando 

Constraint solving is started by the ambulando function, which lazily propagates 
a substitution rightwards through the metacontext, making progress on problems 
where possible. It maintains the invariant that the entries to the left of the 
cursor include no active problems. This is not the only possible strategy: indeed, 
it is crucial for guaranteeing most general solutions that solving the constraints in 
any order would produce the same result. However, it is simple to implement and 
often works well with the heterogeneity invariant, because the problems making 
a constraint homogeneous will usually be solved before the constraint itself. 

ambulando :: Subs -4 Contextual () 
ambulando 9 = optional popR »= \ x -4 case x of 
Nothing -4 return () 

Just (Left 9') -4 ambulando ( 9 o 9') 

Just (Right e) —* case update 9 e of 

e'@(E a ( T , HOLE)) -4 do lower • a T © pushL e' 
ambulando 9 

Q Active p —> do pushR (Left 9) 

solver p 
ambulando [] 

e' -4 do pushL e' 

ambulando 9 

Each problem records its status, which is either Active and ready to be worked 
on or Blocked and unable to make progress. The update function applies a sub¬ 
stitution to an entry, updating the status of a problem if its type changes. 

update :: Subs —* Entry -4 Entry 
update 9 (Q s p) = Q s' p' 
where p' = substs 9 p 

s' \ p = p' = s 
| otherwise = Active 
update 9 e — substs 9 e 

For simplicity, Blocked problems do not store any information about when they 
may be resumed. An optimisation would be to track the conditions under which 
they should become active, typically when particular metavariables are solved or 
types become definitionally equal. 
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Appendix D 
Selected proofs 


This appendix contains details of selected proofs from Chapters 2-6. 


D.l Correctness of unification and type infer¬ 
ence 

Lemma 2.6 (Soundness and generality of unification). 

(a) If 0 O F t = v : * H ©i then 0 O E ©i is a minimal solution of t = v. 

(b) If 0 O | S F a = r : * H @i then 0 O , 5 jZ 0i is a minimal solution of a = r. 

Proof. By induction on the structure of derivations. For each ‘unify’ rule, one 
must verify that it gives a solution (i.e. 0 O [Z 0 X and 0i F r = v : *), and 
that this solution is minimal (i.e. given any other solution 9 : 0 O |Z 0' such that 
0' F 9 t = 9 v : *, there is a cofactor ( : 0j C 0' with 9 = ( ■ t). 

For each ‘instantiate’ rule one must verify 0 O , H □ 0 1; 0! F a = r : * and 
that given any other solution 9 : 0 O , 5 C 0' such that 0'h 9a = 9r : * there is 
a cofactor ( : 0j C 0' with 9 = £ • i. 

The key idea is that the type variables of 0 O and 0i are the same, and the 
definitions made in 0 i must hold as equations in 0 ' for the problem to be solved, 
so the solution 9 can be rearranged to produce the necessary cofactor. I consider 
some of the more interesting cases. 

For the DECOMPOSE rule, solutions to t 0 —> T\ = v\ —>• v\ are exactly those 
that solve t 0 = v 0 A T\ = v\ , so it gives a minimal solution by the Optimist’s 
lemma (Lemma 2.4). 

For the skip-semi rule, suppose that 9 : ©09 C ©' 9 H solves a = so 
©'^Sl - 9 a = 9 (3 : Now 6>|© 0 : 0 O Z 0' by dehnition of the □ relation, so by 



induction there exists £ : ©i □ 0' with 9 = £ • t. Then £ : ©i, □ 0', S is the 
required cofactor. 

For the INST-SKIP-SEMI rule, suppose that 9 : ©o^S C ©',5' solves a = r, so 
©',S' b 9a = 9r : Now ©o declares a by the input conditions (Definition 2.1), 
so 9 a is a ©'-type and 9r is equal to it. Hence 9t does not depend on any 
metavariables in S'. Now all the metavariables declared in S occur in r, giving 
9 : ©o 9 S E ©', and hence 9 : 0 O , H C ©'. By induction there exists £ : ©i C 0' 
such that 9 = £ • i. □ 

Lemma 2.11 (Soundness and generality of type inference). If 0 O b t : r H ©i, 
then ©o G ©! is a minimal solution to the type inference problem for t with output 
t. Similarly, if ©o b t : a H ©i then ©o E ©i is a minimal solution to the type 
scheme inference problem for t with output a. 

Proof. Proceed by induction on derivations. It is straightforward to show that 
©o E ©i and ©i b t : r or ©i b t: a. The more interesting part is establishing 
that the solution is minimal, for which suppose 9 : ©o E ©' is a solution, and 
exhibit a cofactor £ : ©i E ©'. 

The Generalist’s lemma proves the property required for the INFER-GEN rule. 

For the infer-VAR rule, suppose x: {VE.v) € 0 O , 9 : 0 O E 0' and 0' b x:v'. 
By inversion, the proof must consist of the VAR rule, so 0' b 9 {VE.v) >- v'. 
Thus there is some substitution £ : Q',9E □ 0' such that 0' b £ {9 v) = v 1 : * 
and C is the identity on ©'. Weakening 9 gives 9' : 0 O , S C ©',05 and hence 
C • 9' : ©o, S C 0' is the required cofactor. 

For the infer-lam rule, suppose 9 : 0 O C ©' and 0' b Xx.t: v —> r', then 
©', x: v b t: r' by inversion. Now (0, v/a) : 0 O , a:*,x:a □ ®',x:v so induction 
on the first premise gives ( : ©i ,x:a,E □ 0',x:v such that {9,v/a) = ( ■ t and 
0' b t' = C t : *. Thus C : ©i, S C 0' is the required cofactor. 

For the infer-APP rule, the Optimist’s lemma does not directly apply because 
it does not apply to problems with outputs, but the same reasoning applies. 1 
Suppose 9 : 0 O □ 0' and O' b st:r. By inversion, 0'bs:r 'at and ©' b t: r' 
for some r'. Thus induction on the first premise gives ( : ©i □ 0' such that 
9 = </■ l and 0' b £ v = t' —> r : *. Now induction on the second premise gives 
C' : 0 2 E © ; such that £ = (' >■ i and 0' b £' v 1 = r' : *. Since there is a solution 
(£',t/q;) : © 2 ,o;: * C ©' such that 0' b (£',t/q;)u = (£', r/a) (u' -A a) : *, 
Lemma 2.6 applied to the third premise gives £" : 0 3 □ 0' with (£', r/a) = £" • i. 
Now 9 = £" • t so C" is the required cofactor. 

1 The lemma can be generalised to apply to this rule (Gundry et al., 2010), but I omit the 
more general formulation here for simplicity of presentation. 
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For the infer-let rule, suppose 9 : 0o E O' gives 0' b let x — sin t :t', then 
by inversion, ©'^S' b s:v and 0', x: (VE'.v) b t:r' for some v. Now 0' b s: (VE'.v) 
so by induction on the first premise there must be some £ : ©i □ 0 ' such that 
9 = (■ l and 0' b £ a >- (VE'.v). Now ( : ©i, x : a E 0', x : C cr so by induction 
on the second premise there must be some £' : 0 2 , x: cr, H C ©', x : ( a such that 
C = C ■ i and 0', x : (a b (' t = t' : *. Thus (' : 0 2 , S □ 0' is the required 
cofactor since 9 = ■ i and ©' h r = t' : *. □ 

Lemma 2.12 (Completeness of type inference). 

(a) If (0 O ,t) is a type inference problem with solution (9:0 0 C 0', v), then 
0 O h t : t H ©i for some ©i and r. 

(b) If (0 O , t) is a scheme inference problem with solution (9 : 0 O C 0', cr 7 ), then 
©o h t : a H ©i for some ©i and a. 

Proof. Proceed by induction on the derivation of 0' b t: v or 0' b t: a' in the 
transformed declarative system (Figure 2.8, page 25). 

For the VAR case, 0' 3 x : a so 0 O 9 x : a 0 for some cr 0 by definition of 
information increase, and hence the infer- VAR rule applies. 

For the LAM case, (9, t/ol ) : 0 O , a : *, x : a C 0',x:t with v is a solution to 
the type inference problem for t, so by induction, 0 O , a: *, x: a h t : r' H ©^ for 
some 0' and r'. Moreover, 0( = ©i, x: a, S by soundness of type inference and 
they definition of information increase, so the infer-lam rule applies. 

For the APP case, inversion gives 0Ts:r'A t and 0' b t: t'. Two appeals 
to the inductive hypothesis show that inference succeeds for s and t, with types 
v and v'. Now generality of type inference gives C : 02 Q O' such that 9 = ( ■ t 
and 0' b (v = t' —!> r A (V = r'. Then (C,t/q;) : 0 2 ,a : * □ ©' and 
0' b (v = (v 1 -3 t : * so Lemma 2.8 shows that the infer-APP rule applies. 

For the let case, observe that 0' b s: V E.v so by induction using part (b), 
0 O b s : a H ©i for some ©i and a. By generality of type inference, there exists 
c : ©i E 0' such that ©' b ( a >- VE.v. Note that ( : ©i, x: a C 0', x: ( a. Now 
O', x : WE.v b t:r and hence 0', x : £ a b t: r, so the infer-let rule applies by 
induction. 

In part (b), suppose 9 : 0 O E © ; is a solution to the scheme inference problem 
for t, with output VE'.v. Then 0', S' b t:v. Now 9 : 0 O 9 E © ; 5 S' so induction 
using part (a) gives 0 O 9 b t : t H ©^S and hence the INFER-GEN rule applies. □ 
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D.2 Correctness of abelian group unification 


Lemma 3.2 (Soundness and generality of abelian group unification). If the group 
unification algorithm succeeds with © 0 ||TFp= 1:WH ©i, then 0 O , T E ©i is 
a minimal solution of p = 1 \U. 

Proof Proceed by induction on derivations. For soundness, it is easy to verify 
that 9 : ©o,T E ©i and ©i F 9v = 1 : U. Now consider generality for each 
rule in Figure 3.5 (page 37). In each case, suppose 9 : 0 O , T jZ O' is such that 
©' F p = 1 \U, and exhibit a cofactor ( : ©i E ©'. 

For u-trivial, the result is obvious. 

For U-SKIP-SEMI, if T is empty then the result is straightforward. Otherwise, 
T contains a single unknown variable ft: U\ let p = fi k * p'. Moreover, suppose 
9 : ©o , (3 : U E O' $ S is such that O', S F 9 (j3 k * v') = 1. Rearranging gives 
O' 9 E\~ (9 (3) k = (9 p ') -1 but 9 p' is defined over 0' so 9/3 must be defined over 
©'. Thus 9 : ©o, ft : U E © ; and the result follows by the inductive hypothesis. 

For u-SKIP-ty, u-SKlP-TMand U-SUBS, it is straightforward to check that the 
inductive hypothesis gives the required cofactor. 

For u-define, suppose 9 : 0 O , a: U, T E ©' is such that O' h 9 ( a k * v k ) = 1. 
Then ©' F (9 (a * v)) k = 1 and hence O' F 9 («*//) = 1 for the free abelian group. 
Thus O' F 9 a = 9 (p - 1 ) and so 9 = 9- [p _ 1 /q;] :0 O , T E ©'• 

For U-REDUCE, apply the isomorphism lemma (Lemma 2.5, page 18). The 
inductive hypothesis gives that Q 0 ,T,f3: U E ©i is a minimal solution of 
/3 k * R k(y) = 1. Moreover [a * Q^p) -1 //?] : © 0 ,T, ft : U E ©o,« : U,T is an 
isomorphism with inverse [/3 * Q fc (p)/a] : 0 o ,o ;: U,T E ©o ,Y,/3: U, so the iso¬ 
morphism lemma gives that F) 0 , a : U,T E © 1 , 0 ; ■— /3 * Qfc(p) : U is a minimal 
solution of a k * v = 1. 

For u-COLLECT, appeal directly to the inductive hypothesis. □ 

Lemma 3.3 (Completeness of abelian group unification). If v is a well-formed 
unit of measure in 0 O , and there is some 9 : 0 O E © ; such that ©' F 9 p = 1: U, 
then the algorithm produces ©i such that 0 O || • F p = 1 : U H © 1 . 

Proof First, establish termination of the rules when viewed as an algorithm, 
where hypotheses correspond to recursive calls. Termination is by the lexico¬ 
graphic order on the total length of the context (including T), the maximum 
power of a variable in the expression being unified, and the length of the first 
part of the context (excluding T). Only the U-REDUCE and u-COLLECT rules do 
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not decrease the total length on recursive calls; moreover, U-REDUCE decreases 
the maximum power of a variable and u-COLLECT decreases the length of the first 
part of the context. Note that the final result may be longer than the original 
context, due to U-REDUCE. 

The algorithm terminates, so proceeding by induction on the call graph allows 
reasoning about completeness. By inspection of the rules, observe that only two 
possible cases are not covered: either v is a constant that is not equal to 1, or v 
contains exactly one variable a, and the power of a does not divide the powers 
of the constants. In either case, there are no possible solutions of the unification 
problem v = 1:U. 

Finally, note that each rule preserves solutions: that is, if the initial problem 
(conclusion of the rule) has a solution then the rewritten problem (hypothesis of 
the rule) must also have a solution. Hence failure of the algorithm indicates that 
the original problem had no solutions. □ 

Lemma 3.4 (Soundness and generality of type unification). 

(a) If Q 0 \~ r = v : * ~\ 0i, then 0 O C 0i is a minimal solution of r = v:*. 

(b) IfQ 0 \E\-a = r:*-\ 0i, then 0 O , S C 0j is a minimal solution ofa = r:*. 

Proof. Proceed by induction on the structure of derivations, as in Lemma 2.6 
(page 22). The majority of the cases are similar to the previous proof, but 
the unit rule is new, the INST rule has been modified. The INST-SKIP-SEMI rule 
requires a more subtle generality proof, in order to verify that instantiation moves 
only genuine dependencies. The input conditions ensure that units always occur 
in the form F (a ), so it is obvious that a is a dependency. 

For the unit rule, the result follows from the soundness and generality of 
abelian group unification (Lemma 3.2). 

For the INST rule, use the Optimist’s lemma (Lemma 2.4, page 18), which 
states that the minimal solution to a conjunction of problems is found by ‘op¬ 
timistically’ solving the first problem in the original context, then solving the 
second problem in the resulting context. This rule fits the pattern as solutions 
to a = t{ vi l } : * are the same as solutions to (a = t{ /?» }: *) A ’J||= Vi'.U up 
to the equational theory. 

Recall the inst-skip-semi rule 

©o|Sba: = T:*HOi 
00 9 | S b a: = t : * H ©i, , 
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and suppose 9 : 0 O 9 S C 0' 9 S' is such that 0' $ S' h 9 a = 0 t : *. Now a:*£0 o 
by the conditions for the algorithmic judgment, so 0a is a ©'-type and 9 t is 
equal to it. In the previous proof, I argued that Or could not depend on S', but 
this does not hold for the equational theory of abelian groups, because equivalent 
expressions can have different sets of free variables. However, if /3: U e S then 
F (f3) is a subterm of r, so F (6 f3) is a subterm of 9 r and hence there is some of 
©'-unit v with 9 f3 = u. Similarly, if 7 : * e S then 7 e fmv(r) so 9 7 is defined 
over 0'. Hence there is some 9' : ©o 9 5 C 0', with 9 = 9' , so 9' : ©o, S jZ 0' 
and by induction there exists ( : ©i C 0 ' as required. □ 

Lemma 3.5 (Completeness of type unification). 

(a) If the types v and r are well-formed in 0 O and there is some 9 : 0 O |Z 0' with 
0'b 9v = 9t:*, then unification produces ©i such that 0 O hu e r : * H 0i. 

(b) Moreover, if 9 : 0 O , S Z 0' is such that 0' h 9a = 9t :* and the input 
conditions (Definition 3.1) are satisfied, then there is some context ©i such 
that ©0 | H h a = r : * H © 1 . 

Proof. First establish that the system terminates, if viewed as an algorithm with 
inputs 0 O (and S), v (or a) and r, giving outputs ©1 and 9. The ‘unify’ judg¬ 
ments terminate because each recursive call removes a type metavariable from the 
context, decomposes the types or removes a unit metavariable. The ‘instantiate’ 
judgments either shorten the whole context or the part of the context before the 
bar. Note that the INST rule may add unit metavariables, but a type variable will 
be removed from the context by instantiation. Only the DECOMPOSE rule makes 
more than one recursive call to type unification, and it decomposes types so it 
does not matter that the intermediate context may have more unit metavariables. 

Now proceed by structural induction on the call graph, observing that each 
rule in turn preserves solutions, and that all (potentially solvable) cases are 
covered. The only cases not covered are rigid-rigid mismatches (e.g. unifying 
v —y t with F(p)) and the flex-rigid problem a = t in context ©o, a: *, 5 where 
a e fmv(T). The latter has no solutions because the occurs check fails (if a is 
in S then the conditions of the lemma ensure t depends on it), as in Lemma 2.8. 
The algorithm may also fail in abelian group unification, for which completeness 
is by Lemma 3.3. □ 
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D.3 Correctness of Miller pattern unification 

D.3.1 Consistency of the unification logic 

To prove consistency of the unification logic, as described in Section 4.3 (page 
81), it is enough to show that every derivation has a normal form. 

Lemma 4.9. If 0 is solved, 0 | T b P and 8 is a substitution from F to A that 
identifies twins, then 0 | A b <5 P is. 


Proof. By induction on the derivation of 0 | F b P. 


Case 


01 r h ctx 
0irbT 


Trivial. 


0 | T b P wf 


0|Tb P 


By induction, 0 | A b T is, which is 


impossible. 


<d\F,x:S\~P 

Case - . Q\A,x:8S\~8Pis follows from the inductive hypoth- 

0|Tb Vx:S.P 

esis, and hence 0 I A b \/x: 8 S. 8 P is. 


Case 


© I T b (S': Type) ~ ( T: Type) 
e\F,x:StTF P 

Q\F\-Vx:StT.P 


Similarly to the previous case, induc¬ 


tion gives 0 | A b Type 9 8 S ^ U ^ 8 T and 0 | A, x : U b 8 P{x, x] is, and 
hence © | A b Mx : 8 S\8 T. 8 P is. 


Case 


0 | T b Type 3 S^U^T 
Q\F,x:U\- P{x,x} 

0|T b Vx:StT.P 


Similar to the previous case. 


Case 


0|Tb Vx:S.P 
0|Tb S3s 
0 | T b P{s} 


By induction, 0 | A b \/x : 8 S. 8 P is, so inversion gives 


0 | A, x: 8 S b 8 P is. Then 0 | A b <5 P{s} is by the substitution lemma. 
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e|rhVx:5tr.p 
0 | r b Type 3 S^U^T 

0 ir b u 3 u 

Case - . By induction, 0 | A b : 8 S$8 T. 8 P is, 

0 |rbP{u,u} 

so 0 | A b Type 3 8 S ^ U ^ 8 T and 0 | A, x : U b 8 P{x, x} is by inversion. 
Then 0 | A b U 3 5u so substitution gives © | A b 8 P{8 u, 8 u} is. 

0 9? P 0 | r b ctx 

Case - . P is solved, so use Lemma 4.7 (page 81). 

0|Tb P 

Conjunction introduction and elimination. Straightforward appeal to the 
inductive hypotheses. 

© | r h ILc: A B « ILe:5. T 

Case - . The inductive hypothesis gives 

0 \'\- An SAVx:AiS. P{x} « T{x} 

0 | A b Tlx: 8 A. 8 B ~ llx :8 S.S T is so inversion using the definition of is gives 
0 | A b Set 3 Ida;: 8 A. 8 B = fla:: 8 S.S T. Then inversion on the definitional 
equality gives © | A b Set 9 <5 4 ^ U ^ 8 B and 0 | A, x : U b Set 3 8 B = 8 T. 
Thus 0 | A b <5 A « <5 B A Wx : 8 St8 T. 8 B{x} w 5 T{x} is. 

0|rbEi:AB«Ei:S.T 

Case - . Similar to the previous case. 

0\r\- A& S AVx:AtS.B{x}^ T{x} 


Reflexivity, symmetry and transitivity. By Lemma 4.1 (page 65) and the 
definition of 0 | A b (s: S) « (t: T) is. 


T3x:S\T 0|rbctx 

Case - . Here 8 identifies twins, so 

0|Tb (f:5) w {x-.T) 

case that 0 | A b (8x:8 S) (8x:8 T) is. 


it must be the 


Congruence rules (Figure 4.7, page 62). Each congruence rule corresponds 
to a rule of the definitional equality, except for the presence of twins. The hetero¬ 
geneity invariant means that the types of twins are provably equal, so induction 
means they are definitionally equal and can be replaced with a single variable. □ 
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D.3.2 Soundness 


If twins have definitionally equal types, they can be replaced with a single variable: 

Lemma D.l. Suppose 0 | T F Type 9 A ^ U ^ S. Then 0 | T F \/x : A%S. P if 
and only if 0 | T \~\/x: U. P{x,x}. 

Proof For the forward direction, observe that 0 | T, y : U b \/x : AfF. P and in¬ 
stantiate this with (y, y)/x to get 0 | T, y: U F P{y, y}, so 0 | T h \/y: U. P{y, y}. 
For the reverse direction, if 0 | T F \/x : U. P{x, x} then 0 | T, y : U F \/x : 
U. P{x, x) so 0 | T, y : U b P{y, y} and hence 0 | T F \/x : S^T. P{s, t} by an 
inference rule. □ 

The following lemma justifies decomposition of rigid-rigid equations between 
eliminated variables, which is part of the soundness of problem decomposition. 

Lemma D.2. Suppose x-e\x\x' -e' \-3 P, 0 | T F a; • e e .S’ and 0 | F F x' ■ e! e S'. 
Then 0 | T F P wf, and ifQ\T\-P then 0 | T F x ■ e « x' ■ e'. 

Proof. Prove both parts simultaneously by induction on e. □ 

All the judgments are insensitive to ^-contraction: 

Lemma D.3. 

(a) If® | T F T 3 t{Xx.nx} then 0 | T F T 3 t{\x.nx} = t{n}. 

(b) 1/0 |TF T 3 hd, 77-tl) } then © | T F T 3 t{(n w , utl)} = t{n}. 

(c) If® | T{Xx.nx} F P{\x.nx} then ®\T{n} P{n}. 

(d) //0|r{(nHD,riTL)} F P{(nHD,n TL )} then © | r{n} F P{n}. 

(e) If® | T{A x.nx} F P{Xx.nx} is then © | T{n} F P{n} is. 

(f) If 0 | r{(riHD, utl)} F P{(uhd, utl)} is then 0 | T{n} F P{n} is. 

(g) If® | T{A x.nx} F P{Xx.nx} wf and 0 | r{n} F P{n) then 
0 | r{A x.nx} F P{Xx.nx}. 

(h) //0 | r{(riHD, utl)} F P{(nHD, utl)} wf and ®\T{n} \~ P{n) then 
0 | r{(riHD, btl)} F P{(nHD, «tl)}. 

Proof. Parts (a) and (b) are by structural induction on derivations. The remain¬ 
ing parts follow from them by induction on derivations, using context conversion 
(Lemma 4.5) and conversion (Lemma 4.6). □ 
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The problem decomposition operation, summarised in Figure 4.14 (page 79), 
is sound in that it preserves well-formedness and provability of problems: 

Lemma 4.12. If 0 | T h P wf and P 1=^ Q then 

(a) © | T h Q wf, and 

(b) © | T b Q implies 0 | T b P. 

Proof of part (a). For reflexivity (4.1), Q is trivial and hence well-formed. 

For 77 -expanion of functions (4.2), 0 | F h Tfx : A. B « Ida; : S. T from the 
dehnition of problem well-formedness, so 0 | V h A w S A Mx : A\S. B{x\ rs T{x} 
by injectivity. The case of 77 -expansion of pairs (4.3) is similar. 

For rigid-rigid decomposition of equations between Il-types (4.4) or E-types 
(4.5), the second component of the conjunction is well-formed because the first 
component may be assumed as a hypothesis. 

For rigid-rigid decomposition of variable applications (4.6), use Lemma D.2. 
For rigid-rigid mismatch (4.7), Q is false and hence well-formed. 

For 77 -contraction of subterms (4.8), (4.9), use Lemma D.3. 

The cases that drop unused parameters or twins (4.10)-(4.13) correspond to 
proving admissibility for appropriate forms of strengthening. 

Simplification of identical twins (4.14) and E-splitting of parameters (4.15) 
give well-formed results by the substitution lemma (Lemma 4.1, page 65). □ 

Proof of part (b). For reflexivity (4.1), P holds dehnitionally. 

For the steps that perform 77 -expansion and rigid-rigid decomposition of II or 
E-types (4.2)-(4.5), in each case, P follows from Q by a single application of the 
appropriate congruence rule from Figure 4.7. 

For rigid-rigid decomposition of variable applications (4.6), use Lemma D.2. 
For rigid-rigid mismatch (4.7), the proof of Q = _L can be eliminated to 
produce a proof of P. 

For 77 -contraction steps (4.8) and (4.9), use Lemma D.3. 

The cases that drop unused parameters or twins (4.10)-(4.13) correspond to 
proving admissibility for appropriate forms of weakening. 

Lemma D.l proves the required property for simplification of twins (4.14). 
For E-splitting of parameters (4.15), instantiating Q with AA.sAhd for y and 
AA.xAtl for z gives the P (up to uses of surjective pairing, using Lemma D.3). 

□ 
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Lemma D.4 (Soundness of pruning). Suppose 0 = 0 o ,/TIIA. T, ©i. 

(a) If Q b mctx and prune then © 0 | A' b ctx, vars(A') C vars(A). 

(b) If 0 b mctx and pruneTm Vt e->- (/3, A') then 0 O | • b Type 9 IIA'. T and 
0 0 , 7 : IIA'. T | • hnA.T 9 AA. 7 A'. 

Proof Part (a) is by induction on the definition of prune, observing that the 
bindings in A' are a subset of those in A, and that prune retains a binding x: S 
only if the free variables of S have been retained in A'. Part (b) then follows 
from part (a), and the fact that pruneTm checks that fv(T) C vars(A'), so the 
type IIA'. T is well-formed. □ 

Lemma 4.13. If 0 b mctx and 0^0' then □ 0'. 

Proof. By induction on the step taken. 

For inversion (4.16), t:Q,a: T,Q □ 0,0 o ,o; := A x~ t l .t\ T,Q 1 since 0 O , 0i is 
a dependency-respecting permutation of 0 and the solution for a is well-typed. 
Moreover VP. crop t holds since axl 1 = (Axp . t)'% 1 = t. 

For occurs check failure (4.17), the result is trivial since any problem is true 
in a failed metacontext. 

For equation solving by intersection (4.18), observe that VT. axl 1 ~ ayl 1 
holds since axl 1 = (AA.d A') 37 * = (d A' by the definition of intersection, and 
similarly ayl 1 = (AA./3A ')yl l = /3 A'. 

For pruning (4.19), use Lemma D.4. 

For pruning failure (4.20), the result is trivial since 0' is failed. 

For S-splitting (4.21), it suffices to check that if 0 | • b Type 9 IIA. Ex: S. T 
then 0|- b Type 9 IIA. S; 0,ao : IIA. S \ ■ b Type 9 IIA. T{a 0 A} and 
0, ao: nA. S , : nA. T{a 0 A} | • b IIA. Ex:S. T 3 XA.(a 0 A, on A). 

For uncurrying (4.22), a similar check is needed. 

For problem decomposition (4.23), Lemma 4.12 gives that 0, ? VT. P b mctx 
and P & Q implies 0, ? VT. Q \ ■ b VT. P, since 0, ? VT. Q \ T b Q. 

For conjunction splitting (4.24) and removing trivial problems (4.25), the 
result is trivial. 

For the symmetry step (4.26), the result follows by induction and symmetry 
of the definitional equality (Lemma 4.4). 

For the suffix step (4.27), observe that if 0: © C 0' and 0, 0 O b mctx then 
0 ', # 0 O b mctx and weakening means that (6, l) : 0 , 0 O E ©', # 0 o- □ 
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D.3.3 Generality 

I will need standard no confusion and no cycle results for the definitional equality, 
in order to prove that the steps that reject impossible equations are most general. 

Lemma D.5 (No confusion). If s JL t then there are no 0 and T such that 
0|T b T 3 s = t. Moreover, if s JL t then 9 s JL 91 for any metasubstitution 9. 

Proof. By induction on the derivation of s ± t, and inversion on the definitional 
equality relation for the first part. □ 

Lemma D.6 (No cycle). Suppose t contains a strong rigid occurrence of a t,; 1 . 
or a rigid occurrence of ayi 1 . Then there are no 0, T, 9 and T such that 
0|Tb T3 9(ax~ i i ) = 9t. 

Proof. Suppose otherwise, and without loss of generality assume that 9 substi¬ 
tutes Xxi l .siora,so9(aXi l ) = s. If a tj l occurs strong rigidly (under a canonical 
constructor such as II) in t, then [ ti/xi ] s = [ U/] {9 t) occurs strong rigidly in 
9 t. But substitution cannot remove strong rigid occurrences of subterms, so re¬ 
peating this observation shows that s contains an infinitely deep tree of canonical 
constructors, which is a contradiction. 

If ayi 1 occurs rigidly (under a canonical constructor or variable) in t, then 
[ Vi/xi ] s occurs rigidly in 9 t. Now renaming does not change the size of a term, 
so s is the same size as a subterm of itself, which is a contradiction. □ 

Lemma D.7. //0|rb T 3 s = t then f v(s) — f v(t). 

Proof. By induction on the derivation. □ 

Lemma 4.15 (Generality of problem decomposition). J/0 | T b Pwf, the meta¬ 
substitution 9: 0, ? Vr. P C ©' is a solution and P 1=^ Q, then 9: 0, ? VT. Q C 0'. 

Proof. Lemma 4.2 (page 65) implies ©' | • b 9 (VT. P), so ©' | • b 9 (VT. P) is by 
Corollary 4.10 (page 82). Now proceed by case analysis on P l=>- Q, supposing 
that 9 (Vr. P) is solved and showing that 9 (VT. Q) is solved. Without loss of 
generality assume that T contains no twins , 2 so suppose 0' | 9T b P is and show 
that 0' | 9T b Q is. 

For reflexivity (4.1), Q is trivial. 

For the ^-expansion and rigid-rigid decomposition steps (4.2)-(4.6), each case 
follows from inversion on the definitional equality: for example, consider the rule 

2 By definition, a problem involving twins is solved if the types are equal and the correspond¬ 
ing problem without twins is solved. 
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for n-types (4.4). If 0' | 0T b Set 3 Ux:9 A.9 B ^Ux: U. V ^ Ilx: 9 S. 9 T then 

e' | er h set 9 e a =[ u ]= e s and e' | ev, x ■. u b set 9 e b =[ v ]= e t by 

inversion. Hence 0' | • b 9 (VT. A fa S A Vx:A$S. B{x} « T{x }) is. 

For the rigid-rigid mismatch step (4.7), observe that metasubstitution cannot 
remove rigid differences, and rigidly different terms cannot be definitionally equal, 
by Lemma D.5. Thus there can be no solution 9. 

For the ^-contraction steps (4.8) and (4.9), use Lemma D.3. 

The cases that drop unused parameters or twins (4.10)-(4.13) correspond to 
proving admissibility for appropriate forms of strengthening. 

For simplification of twins (4.14), there is nothing to prove, as the definition 
of VT :StT.P is means 0 | T b Type 9 S ^ U ^ T and VT: U. P{x, x} is. 

For E-splitting of parameters (4.15), use Lemma 4.7 (page 81). □ 

Lemma D.8 (Generality of pruning). If pruneTm (fv(e)) t i—)■ (/3, A') and there 
is some 9:Q,/3: nA. T, 0' C 0i such that 0i | 9T b U 3 9 (a-e) = 91, then there 
exists C: ©, 7 : nA'. T, j3 := AA.y A': nA. T, 0', ? VT. a ■ e & t C 0i with 9 = ( ■ t. 

Proof. Let 9 = (9 o ,s//3,0i) and observe that s = XA.u up to ^-conversion. To 
see that fv(u) C vars( A'), suppose otherwise, i.e. assume^ e fv('u)\vars(A'). By 
definition of pruning there is some subterm fd U 1 of t such that prune V A f * i->- A'. 
Thus 9 t contains some 9 tj with fv ng (# if) <f_ V. Hence f m{ 9 t ) f \/(9 (a-e)), which 
contradicts Lemma D.7. Thus fv(u) C vars(A'), so the cofactor Q can be taken to 

be (0 o ,(AA'.u)/7,(AA.u)/0,0i)- □ 

Theorem 4.16 (Generality). If Q 0 h mctx, the metasubstitution 0:0 O G ©' is 
a solution and 0 O 0 i then there exists a cofactor £: 0i C 0' such that 9 = (-t. 

Proof. By induction on the step taken. In each case, construct a suitable cofactor 
£. If the induced metasubstitution i : 0 O C ©i is an isomorphism, its inverse can 
be composed with 9 to obtain the required cofactor (Lemma 2.5, page 18). 

For equation solving by inversion (4.16), let £ be the appropriate permutation 
of 9. Observe that 9 is a solution so 0'| • h # (VT. axi % ~ t) is and hence 
0'|0r h T 3 (0a)xT = 91. Then 0'|- h nA. T 3 9 a = 9{Xx i i .t) by 
congruence of A, ^-expansion and strengthening, so 9 = £ • i. 

For occurs check failure (4.17), there can be no solution 9 by Lemma D. 6 . 
For equation solving by intersection (4.18), 0'| • b 0 (VT. axi 1 « Oiyl 1 ) is 
implies 0' | 9T b T 3 (9a)xif ■= (9a) pi 1 . Up to 77 , 9a is of the form XA.t, 
and any variable bound in A corresponding to distinct variables in xp and yp 
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must not occur in t, as the above definitional equality would fail. Hence £ can 
substitute A A ' .t for /3. 

For pruning (4.19), use Lemma D.8. 

For pruning failure (4.20), observe that metasubstitution cannot add free 
variables (i.e. f m{ 9 s) C fv(s)) or remove rigid occurrences of free variables (i.e. 
fv ng (s) C fv ng (#s)), so the existence of a solution would contradict Lemma D.7. 

For E-splitting (4.21), the induced metasubstitution is an isomorphism, with 
the inverse given by substituting AA.cthd for « 0 and AA.ojtl for ot\. 

Similarly, uncurrying (4.22) induces an isomorphism (with the inverse given 
by currying). 

For problem decomposition (4.23), Lemma 4.15 shows that £ = 9 suffices. 

For conjunction splitting (4.24) and removal of trivial problems (4.25), the 
induced metasubstitution is an isomorphism. 

For the symmetry step (4.26), the result follows from the inductive hypothesis 
and the fact that definitional equality is symmetric. 

For the suffix step (4.27), the result follows by induction. □ 

D.3.4 Partial completeness 

Lemma 4.17. Suppose 0 is a well-formed metacontext in the pattern fragment 
that is not solved or failed. Then 0 0' for some 0' in the pattern fragment. 

Proof. By case analysis on the first unsolved problem in 0, using step (4.27) to 
skip later problems. If the first problem is a conjunction, step (4.24) applies. If 
not, it is of the form VT. (s : S) ~ (t : T). Without loss of generality, assume 
that r contains no twins (otherwise they can be removed by step (4.14)). Mow 
0|T h (S : Type) ~ ( T : Type) by the heterogeneity invariant, and hence 
0 | T h Type 3 S = T by Corollary 4.10. In particular, f v(S) = fv( T) by 
Lemma D.7. 

If /3 • e' is a subterm of s or 1, the pattern condition means that e' consists 
only of projections and applications to variables. But any projections may be 
eliminated by the lowering step (4.21), so assume it includes only variables. 

Now consider the possible cases for s and t. If they are identical, then step 
(4.1) removes the reflexive equation. If one of them is a function or pair, then 
the appropriate ^-expansion step (4.2) or (4.3) applies. 

If they are both rigid, then either the heads match so one of the decomposition 
steps (4.4)-(4.6) applies, or they do not and the algorithm fails with (4.7). 
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Otherwise, one of them is flexible. Suppose without loss of generality, using 
the symmetry step (4.26) if necessary, that s — axi\ and consider the possible 
cases for t. 

If t = aYi 1 then step (4.18) applies: intersection always succeeds, and the 
condition on the free variables must hold since S and T have the same free 
variables, so any variable removed by intersection cannot occur in the type of a. 

If t has a flexible occurrence of a variable that is not one of the Xi *, then 
pruning will take a step (4.19); the pattern condition ensures it will not get 
stuck. If t has a rigid occurrence of a forbidden variable, then unification will fail 
with step (4.20). 

If t contains a rigid occurrence of a, then the occur check step (4.17) ap¬ 
plies, since the evaluation context of a consists only of variables. By the pattern 
condition, t contains no flexible occurrences of a. 

Finally, to apply the solution step (4.16), an appropriate permutation of the 
metacontext must exist, so that all the dependencies of t can be moved before 
a. Observe that the type of t does not transitively depend on a, since it is equal 
to the type of axl*. Now by induction on the typing derivation for t, using the 
pattern condition and the fact that t does not contain a, none of the subterms of t 
have types that depend on a. In particular, none of the metavariables that occur 
in t have types that depend on a, so an appropriate permutation exists. (This 
induction requires the result type of an if-expression to contain no metavariables.) 

□ 

D.4 Consistency of evidence language coercions 

The overall structure of the consistency proof for coercions in the evidence lan¬ 
guage is described in Section 6.5 (page 131). Here I will detail the proofs that 
were previously omitted, and prove required additional results. 

Note that the reduction relation is closed under substitution: 

Lemma D.9. If p kpush > p' then [<5/ A] p kpush > [5/A] p'. 

Proof. By induction on the reduction step used. □ 

Lemma 6.14 (Transitivity). If A k (r ~ v) and A k (v ~ /c) then A k (r ~ n). 

Proof. Proceed by induction on k and inversion on A* (</?). 

Consider the case for quantifiers, where A/.((ai : T fiq) —>• T\ ~ (a 2 : T k 2 ) —> t 2 ) 
and A fc ((a 2 : T k 2 ) —> t 2 ~ (a 3 : T k 3 ) —>• r 3 ). By definition, A*^ : «q ~ k 2 ) 
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for some 71 , and A k (n 2 ~ k 3 ), so induction gives A /c (k i ~ k 3 ). In order to 
demonstrate that A*,((ai : T K 7 ) —>■ T\ ~ (a 3 : T k 3 ) —>■ t 3 ), suppose v\ and v 3 have 
A^((vi : Ki) ~ ( v 3 : k 3 )) for l < k, and seek to prove Ai([vi/a 3 \ ~ [v 3 /a 3 ] t 3 ). 
But A;([^i/ai] ri ~ f«4 > 7 i/« 2 ] T 2 ) and A;([-ni > 7 i/a 2 ] t 2 ~ [^ 3 /a 3 ] T 3 ), so the 
result follows by induction. 

The other cases where all three types are structural are similar. 

If all three types are computational, then they can each take a step by defini¬ 
tion, and the reducts are related by induction. 

If t is computational but v and k are structural, then the definition gives r' 
structural or coerced such that r — y* r' and A k (r' ~ v). Then induction gives 
A k {r' ~ k) and hence A k (r ~ k) by definition. 

If t and v are computational but n is structural, then the definition gives v' 
structural or coerced such that v —>* v' and A fc (V ~ k). Then there exists r' 
such that t — y* t' and A k (r' ~ v'), so induction gives A fc (r' ~ k) and hence 
A k (r ~ k). 

The other cases where some of the types are computational and some are 
structural are similar. 

If any of r, v and k are coerced, then the coercion(s) can be removed and the 
underlying types are compatible by induction. □ 

I need a couple of auxiliary results to prove that compatibility is closed under 
reduction. The first is straightforward. 

Lemma D.10. Suppose • h H : v (A) —>• r and ■ b tc ou : A. Then for any k, 
A fc (H to ~ H at) if and only if A k (cu : A). 

Proof By induction on the length of a;. □ 

Showing that compatible expressions satisfy progress is more interesting. This 
does not imply progress in general, because only type expressions (at phase V) 
are covered and they must be in the diagonal of compatibility. 

Lemma D.ll (Progress for compatible expressions). If A k {r ~ t) for k > 0 
then either r is a coerced value type or t can take a step. 

Proof. By induction on r and inversion on Apfr ~ t). If r is computational 
then the definition states that it can take a step. If r = t' > 7 is coerced then 
A k (r' ~ t') so by induction either r' is a coercion, a coerced value or can take a 
step, which implies the result. Otherwise, r is structural: either it is immediately 
a value type, or it is an application r' p and A fc (r' ~ r') so induction on r' implies 
the result. □ 
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To deal with one coercion being cast by another, I need to show that compat¬ 
ibility of two propositions (tpi ~ p 2 ) means compatibility of tp\ implies compati¬ 
bility of tp 2 . Observe that tpi and tp 2 are syntactically restricted to be quantified 
equations, not arbitrary types. Proving this lemma is the motivation for restrict¬ 
ing quantification at phase □ to syntactic propositions only. 

Lemma D.12. If A k (tpi) and A k (tpi ~ tp 2 ) then A k (tp 2 ). 

Proof. Proceed by induction on k and case analysis on p 1 and tp 2 . Since they are 
both equations or quantified propositions, the definition of A k (tpi ~ tp 2 ) implies 
that they have the same form. 

If (pi = T\ ~ Vi then tp 2 = t 2 ~ v 2 where A k (fx ~ r 2 ) and A k (vi ~ v 2 ). 
Moreover A k (ri ~ 77), so A k (r 2 ~ v 2 ) by transitivity (Lemma 6.14). 

If ipi = (ci : D tpQ ->• tp” then tp 2 = (c 2 : D <p' 2 ) -»■ . For A fc ((c 2 : D tp 2 ) ->• ^ 2 ), 

suppose 77 is such that Afrj : tp' 2 ) for some l < k. Now A ;(7 : p 2 ~ ip[) for some 
7 by definition of A k (tpi ~ tp 2 ) and downward closure (Lemma 6.15, page 135). 
By induction, Ai(j] > j : tp \). Then A ;([77 > 7 /ci] </?" ~ [ 77 /c 2 ] </? 2 ) by definition 
of A k ((pi ~ </? 2 ). Moreover, A/Q 77 > 7 /ci] tp") by definition of A k (tpi). Hence 
A;([? 7 /c 2 ] tp 2 ) by induction, so A k ((c 2 : a tp 2 ) —>• tp §} as required. 

If </?i = (x'i Ati) —>• (p) then <p 2 = (x 2 :^r 2 ) —>• (p 2 . Now the assumptions imply 
A fc ((/? / 1 ) and A fe ((/? / 1 ~ <^ 2 ), so A*^) by induction, and hence A k {tp 2 ). 

Finally, if tp x = (cq : T k%) —> tp' % then tp 2 = (a 2 : T k 2 ) —>• ^ 2 . To show 
Afc((a 2 : T k 2 ) — > tp 2 ), suppose • h r : v tc 2 and A/(t ~ r) for some l < k. Now 
Afc(<£>i ~ tp 2 ) implies A k (r] : tc 2 ~ «ij for some 77 . Moreover, Aj([r t> 77 /ojJ v^i) 
and A ; ([r > 77 /ai] tp\ ~ [r/a 2 ] <£> 2 ) follow from the assumptions, so A ; ([r/a 2 ] tp' 2 ) 
by induction. Hence A fc ((a 2 : T 7c 2 ) —¥ tp 2 ) as required. □ 

The following result shows that the step coercion preserves compatibility. 

Lemma 6.16 (Reduction preserves compatibility). If t kpush > v and A k (r ~ r) 
then A fc _i (t ~ r;). 

Proof. By induction on k and the reduction step r —> v. 


Case 



If A k (p\>r) 


p>rj ) then A k (p ~ p) and A k _ x {r) : < 7 ?). 


Hence A k _ i( p ~ p') by induction, so A k _ i( p > 77 ~ p' > 77 ) as required. 
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Case 


If A k{pp" ~ P p") then A k (p ~ p) so by induction 


p - 

-> ft 

pp" - 

-»• p' p" 


A fc _i(p ~ p') and hence A k _i(pp" ~ p' p”). 


case p of bfj 1 - 


^ J hr- 


■=7 - If A*( 


case o of hr „• 


then Afc_ i( case p' of ~ case p' of bri *) by definition. By Lemma D.ll, there 
is t with case p' of bri — > r, and induction gives A fc _ 2 ( case p' of bri ~ r). 
Hence by definition A k _ i ( case p of hr t ~ case p' of ). 


Case 


kpush < 

£ — - > £ 

br' 0 = bro > step £ ... br' n = br n > step £ 


dcase £ of br 0 ... br n —> dcase s' of br' 0 ... br' n 


Similar to previous case. 


K A —>• p e bri 


case K -0 S of bri 


• [S/A }P 


If A fc (case K0 <5of Sift ~ case K 0 <5 of br^ *) then A fc _i( [<S/A] p ~ [<5/A]p) by 
dehnition. If [S/A]p is computational, then proceed as in the previous two cases. 
If it is structural, then A*, _ i ( case K -0 8 of br * ~ [<5/A]p) is immediate from 
the dehnition. If it is coerced, then unwrap coercions until a computational or 
structural type is reached, and the required property follows as before. 


Case 


K A -y p e br t * 

dcase K ijj 6 of br ,■ * —> [(6,{Ki/;5))/A]p 


Similar to previous case. 


Case 


/(*)—►[*/A] p 


Similar to previous case. 


r h 7 : D ((ai: T ^i) —> Tj.) ~ ((a 2 : T k 2 ) —> r 2 ) 

Case 7 ° = Sym ^ eft 7 ^ 71 = 7@ ( Coh ( r ) 7 °) 

(v > y) T r —» v T (r > 70) > 71 

If Afc( (v > 7) r ~ (v > 7) r) then the dehnition gives A fc ( v ~ v), A k (r ~ r) and 
A fc _i(7 : (ai : T /ci) ->• Ti ~ (a 2 : T k 2 ) -> r 2 ). Hence A fc _i( v > 7 ~ v). Now 
A/s_ 1 (70 : ~ «i), so A*_i(t ~ t> 7 0 ) and A fc _ 2 (7i : [t>7 0 /oi]ti ~ [r/a 2 ]T 2 ). 
Thus A fc _i( (v> 7) t ~ v(r>7o) >71). 
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• If A fc ((v>7)7? ~ (v>7)77) 


Th 7 : a 

Case 70 = Sym ^ eft 7 ^ 71 = 7@ ^ > 7 °’ ^ 

(v>7 ) a r] —* v n (?7>7o) >71 

then A fc ( v ~ v), A fc _i (77 : <p 2 ) and A fc _i (7 : (ci: D v?i) (c 2 : D ^ 2 ) -7- r 2 ). 

Hence A fc _i(v >7 ~ v). Now A fc _i( 7 0 : <^ 2 ~ (pi), so A fc _ 2 (? 7 > 7 o : <Pi) by 
Lemma D.12, and A/,_ 2 (7 i : [77 o 7o /Ci] T\ ~ [ 77 /c 2 ] r 2 ). From this it follows that 
A/e_i( (v > 7 ) 77 ~ v (77 > 70 ) > 71 ). 


Case 


r h 7 : D ((oi: a ki) -4 n) ~ (( a 2 -. k K 2 ) ->• r 2 ) 

7o = sym (left 7) 71 = right 7 

(v > 7) A p —* v A (p > 70) > 71 


If A fc ( (v>7 )p ~ (v> 7 )p) 


then A fc (v ~ v), A*(p ~ p) and A fc _i(7 : (01 : A Ki) -y n ~ (o^A/^) -7 t 2 ). 
Hence A fc _i( v>7 ~ v). Now A fe _1(70 : k 2 ~ «i) and A fc _ 2 (7i : ti ~ r 2 ). Hence 
Ajfe_i(p ~ P> 7 o) and so A fe _i( (v> 7 )p ~ v(p>7 0 ) >71). 


Case 


(v > 7) > 7' —y v > (7; 7') 


If Afc( (v>7)>7' ~ (v>7)>7 ; ) then A*.( v ~ v), 


Afc_i(7 : t 0 ~ Ti) and A fc _i(y : n ~ t 2 ). Transitivity gives A fc _i(T 0 <v r 2 ) and 
hence A fc ( (v> 7 ) >7' ~ v> (7; 7')). 


rh 7 : D Drf ~ Dr tS 
S» K:«(5T7^‘, A)^Da;‘ 

u; = (Ti, 77 , nth* 7 ) : a,i -y Ki -< S : A 

p aS p v _ 

(Kt^)»7^K^ 

If A fc ((Kr7*5) > 7 ~ (Kf 7 *< 5 ) > 7 ) then the definition gives A fc (K 77 * <5 ~ Kt 7 * 5 ) 
and A fc _!(7 : D 7 ' ~ D 77 *). Lemma D.10 gives A k _ 17 , nth* 7 ) : a,- : v k , ) 
and Afc_i((Tj, 77 , nth* 7 ) ,u; : a, : v Ki , A) follows from the definition on coerced 
types since telescoped coercion extension appends coerced copies of types. Hence 
A*-.i(K 8 gptr - K Igf at) and so A fc _i((KSpM) >7 ~ K77* at) as required. □ 

To prove congruence for case analysis, I need that whenever an expression is 
equivalent to an applied constructor, the expression reduces to the same head 
constructor (possibly under a coercion). This follows from the definition of com¬ 
patibility on structural expressions. 
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Lemma D.13. If A&(H 8 ~ r) then either r —>* H S' or r —>•* H 5' > 7 , and 
A k (H8~H8'). 

Proof. By induction on the length of d and the structure of r. □ 

Lemma 6.17 (Congruence for case analysis). If A k (e ~ e') and A k {br.i ~ hr') 
/or all i, then A^((d)cases of br^ ~ (d)cases'of br^ ). 

Proof. By induction on k, £ and s'. 

If e kpush > c 0 and s' kpush > s' 0 , then Lemma 6.16 (page 135) and transitivity give 
Ayfc_i(so ~ s' 0 ), and A fc _i((d)casesoof bri ~ (d)cases' 0 of ) by induction, 
so the result follows. 

Suppose without loss of generality that s cannot step, then by Lemma D.ll 
either k = 0 (and the result is trivial) or s is a value. It cannot have an outer¬ 
most coercion, since Lemma D.13 ensures the case scrutinee push step would be 
applicable. The canonical forms lemma (Lemma 6.12) means that s = K Tj * S. 
By Lemma D.13, s' —»* K rf S' and A k (K rj l 8 ~ Krj*d'). 

For case expressions, there are K A 0 —>• t 0 e hr.,- and K Aq — >■ Tq G br\ , so 

case Ktj 1 5 of br/ —)• [<5/A 0 ]t 0 and case K rj * S' of br \* —)• [<5'/ Aq] Tq. 

Moreover A fc (KA 0 —>• r 0 ~ KAq —» Tq) gives Aa,((A 0 /X\ Aq) —> (r 0 ~ r')). 
Instantiating this with <5 and 8' yields A fc _i([d/A 0 ] r 0 ~ [<$'/A(,] Tq), so 

Afc(case K Tj l 8 of ~ case K rj 8' of br[ ). 

Now A fe (case s' of br\ ~ case K rj <5' of 6 r' ) follows from Lemma 6.16 since the 
left side reduces to the right side, so A fc (casesof ~ case s'of br\ ). 

The argument for dcase expressions is similar: 8 and 8' are replaced with 
8, (K Tj l 8) and <5', (K rj* 8')\ proof irrelevance means nothing more is needed. □ 

If 8 is a vector then let ((8)) be the telescoped coercion with \(8)) = 8 — ({sj) 
and the coercion proofs given by reflexivity. Note that T b 8 : A is equivalent to 
TM c «<5» : A. 

Finally, I can prove the key result, that well-typed coercions are compatible. 
This is a massive mutual structural induction on typing derivations, using the 
preceding results. Unlike most of the previous results, however, k is quantified 
inside the inductive hypothesis, because some cases need to increase it when 
making appeals to induction. 
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Lemma 6.19 (Basic Lemma). 

(a) IfT b r : v k then for all k, A k (uj 0 : T) implies A fc ([it^/r] r ~ po/T] t). 

(b) If T h hr : v v ► r or T h br : v (s : v) ► r then for all k, A k {u 0 : T) implies 
A fc ([^/r] br & [wo/r] 6r). 

(b) //r h 7 : D (p then for all k, A k (ui 0 : T) implies A k ([t*j^/T] (p) and A k ([uo/F] <p). 
(d) //rh tc w : A then for all k, A fc (o;o : T) implies A k ([u 0 /T]cu : A). 

Proof of part (a). Fix k and u > 0 such that A k (u 0 : F). Proceed by induction on 
the derivation of T h r : v k to show A^Qcl^/r] r ~ po/T] r). 



that tf - fe/rj 6 and at = po/F] 5. Then the goal A^Qc^/T] f(5) ~ po/T] f(8)) 
is A k (f(tj) ~ /(at)). Now f(tj) —>■ [ 1 F/A]t and /(at) —> [at/A]r where 
E 3 /[A]=t:* «. Moreover, induction using part (d) gives A k _i(u : A), and 
A*;_i([tr/A] t ~ [at/A]r) follows since the function definition is good. Hence 
A k (f(tu) ~ /(at)) as required. 


T h p (a: $ «q) -4 k 2 r h p' ^ «q 

r h pV [p7«] 

By induction, A k ( [t5/F] p ~ po/T] p) and A k ([^/T]p' ~ po/T]p'). Now 
A fc _!([^/r] ((a Ki) —> k 2 ) ~ po/r] ((a «i) —>■ k 2 )) by Lemma 6.18, so 
the definition on quantifiers gives A fe _ 1 ([^/r] ([p'/a]/c 2 ) ~ po/T] ([p'/a] /c 2 )). 
Hence A fc ( [c^/r] (pp') ~ po/T] (pp')) as required. 
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Case 


Tb k : v * r,a:%hr: v * 

rh(a: $ /t)4r : v * 

To show A fc ([^/T] ((a n) —>• r) ~ po/T] ((a 4 /c) -4 t)), first observe that 
Afc([^/r]/c ~ [4/T] k) follows by induction. Suppose l < k, v and v' with 
A i(v ~ v'), then A i([v/a\ [^/T] r ~ [ v'/a] po/T] t) also follows by induction. 


rb p k r b 7 : D k ~ 

V + □ 

T bp> 7 :* re' 



Here A k ([tj^/T]p ~ po/T]p) by induction, and Afc_i([&a/r] (re ~ re')) and 
A a . \ ([4/T] (re ~ re')) by part (c). Hence A*( [^/T] (p>q) ~ po/T] (p> 7 )). 



and congruence for case analysis (Lemma 6.17). 


Case 


r b£ : n //* V 'F ^ □ 

T b br 0 (s : v) ► r ... T b br n (e : v) ► r 
T b dcaseeof br 0 ... br n :' 5> r 


As previous case. 

□ 


Proof of part (b). Fix A; and cuo such that A k (uj 0 : T). Proceed by induction on 
the derivation to show A fc ([cp/T] br « po/T] 6 r). 


Case 


E9K: $ (of : v re/, A) ->■ 

T, p/c/] A b p r 
T b r : v * <F H/ 
r b K ([p/a/] A) ->• p Dp/ ► r 


First let A' = [p/a* ]A and 


A" = gS^/T] A' A\ [4/r] A'. The goal is A/(A") -4 [^o/r]p ~ po/T]p). 
Equivalently, suppose u is such that A k (uj 0l u : T, A'), then it suffices to show 
Afc( [(a;o,o;)/r, A'] p ~ [p 0 ,<^/T, A'] p), which follows from part (a). 
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s 3 K :* (g, :%>) -» Dai* 

A' = [vi/aS] A//n, c : D £ ~ (K^ l 'A) 

r, A' b p t r h t : v * $ m- n // ^ 

Case - . Similar. 1||! 

rhKA'^p :* (e: D^ 1 ’) ►r 

Proof of part (c). Fix k and u> 0 such that Apcu^ : T). Proceed by induction on the 
derivation of T b 7 : a ip to show A fc ([^/r] ip). In each case, it is straightforward 
to further show A fe ([uIo/T] ip). 



tion, and part (a) gives Afc([^/r]r ~ [c5o/T]t), so A fc ([it^/r] [t/o\ ip) follows 
immediately from the definition. 


rh 7 : D (c: a ip') ^ ip 

T \- rj P <p' , 

Case - . Induction gives A fc ([n^/r] (cPip') —>■</?) from the 

T b 7 ° 77 : D [ 77 /c] ip 

first hypothesis and A fc ([^/F] ip') from the second, so A fe ([cl^/T] [ 77 /c] ip) follows 
from the definition. 


p a k h 7 : D r 

Case --- . First suppose <f> ^ □, and let r be such 

r b AaPn.'y : D (aP k.) —>■ r 

that • F t : v k and A k (r ~ r). Induction gives A fe ([(tOo, t)/T, i 
A fc([c5o/T] ((a: $ «;) — > ip)) as required. The case <F = □ is similar. 


r i- ctx 

E 9 C 

■*ip 

rh c 




Case - . 

rh c P ^ 

hence A fc ([£^/r] ip) since ip is closed. 


Here the goodness of E gives A fc (<p) and 
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A,([^/P] {k\ ~ n 2 )) by definition. 


7 : D («i Ti) ~ (k 2 - 
r b right 7 : n Ti ~ t 5 


Here the inductive hypothesis gives 


A*([4/r](( K 


{n 2 -> r 2 ))), so A fc ([d^/r] (t! ~ r 2 )) by definition. 


Case 

By induction, A*. + 1 ([£^/r] (ti ~ t 2 )) and A^Qc^/T] (77 ~ v 2 )). Moreover 
Lemma 6.18 gives A fc ([^/r] (((ai —> K0 ~ ((a 2 i' 1 ’ k 2 ) —> k 2 ))) and hence 

A*_i([&/r] (K/ai] «i ~ [u 2 /a 2 ]/d,))- Thus A fc ([<t^/T] (ti rq ~ r 2 t; 2 )) as re¬ 
quired. Note that this case relies on the fact that k is universally quantified 
inside the inductive hypothesis. 



rb 7 : D (n:(ci 

D ^i)- 

-t «i) ~ { t 2 : (c 2 : 

D ^2) — t ^2) 

r I-771 : D (pi 

r l 

772 : D <b 2 


T b conga n 

7(^1, 

m) : D (Ti Vi) ~ 

(^2 772 ) 


Similar to previous case. 
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T, a\ : T Ki I- ri : v * T, 02 : T /c 2 b t 2 : v * T b 77 : D K\ ~ /c 2 

T h 7 : D (ai : T Ki, a 2 : T /c 2 , c : a ai ~ a 2 ) —> Ti ~ t 2 

Case - . 

T b cong T 77 7 : D ((oi: T /ci) -4 n) ~ ((a 2 : T /c 2 ) -4 r 2 ) 

A fc ([^/r] (/ci ~ /c 2 )) and A fc ([^/r] ((ai /c 1; a 2 /c 2 , c : D oq ~ a 2 ) -4 Ti ~ r 2 )) 

by induction. Hence A fc ([c^/r] (((ai^/ci) -4 77) ~ ((a 2 : $ /c 2 ) ~4 r 2 ))). 


T, ci : a </?i b Ti : v * T, c 2 : D <p 2 b r 2 : v * 

Case r h *7 Pi ~ ^2 T b 7 : D (ci : D <pi, c 2 : D <p 2 ) -4 n ~ r 2 

T b cong □ 777 : D ((ci: D ^i) -> 77) ~ ((c 2 : n <p 2 ) -4 t 2 ) 
Similar to previous case. 


T b 7 : D e ~ e' T b 77 0 : D br 0 « br ' 0 ... F b rj n : D br n « 6r' 

Case - . 

r b (cong (d)case 7777*) : n ((d)caseeof 6rj l ) ~ ((d)casee'of ) 

By induction and Lemma 6.17. 


Case 


r b 7 : D ip 

r b 77 : D (p ~ </?' 
T b 7 > 77 : D ( p ' 


By induction, A^Qc^/T] <p) and A fc ([^/r] (< 7 ? ~ </?'))■ 


Then Lemma D.12 gives the required result. 


T b 7 : D ((ai: T /Ci) -4-17) ~ ((a 2 : T /c 2 ) —>■ r 2 ) 

Case rl_?7 ;D ~ (^2:^2) 

T b 7@?7 : D [ui/oi] Ti ~ [n 2 /a 2 ] t 2 

Here induction gives A^ + iQ^/T] (((01 : T /ci) -4 77) ~ ((a 2 : T /c 2 ) -4 r 2 ))) and 
A*([fe/r] (ni ~ f 2 )), SO by definition, A fc ([^/T] ([t;i/ai] r x ~ [n 2 /a 2 ] r 2 )). 


Tb 7 : D ((ci: n ^)^r r )~((c 2 : D ^)^r 2 ) 
r b 771 : a v^i rb 772 : D p 2 

T b 7@(771,772) : D [771/ci] Ti ~ [772/02] ?2 


Similar to previous case. 


Case 

T b 7 : D (ti :/Ci) <v (t 2 :/c 2 ) 
r b ?7 : D /Cl ~ v 

. By induction, A^Qc^/T] (77 

T b coh7 77 : a Ti > 77 ~ t 2 

A/,.. i([£o/r] (/Cl ~ k 2 )). Hence A fc ([^/T] (77. >77 ~ r 2 )) as required. 
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r hr' 


r b stepr : D r ~ t' 


Here induction using part (a) gives A k + 1 ([tto/r] (r ~ t)), and Lemma D.9 gives 
[it^/r] t kpush > [itio/r] t', so Lemma 6.16 gives Aj-Qc^/r] (t ~ t')). 


r b 7 : D ~ (t 2 :k 2 ) 

r b kind 7 : D K\ ~ k 2 


By induction and Lemma 6.18. 


□ 


Proof of part (d). Fix k and uj 0 such that A k (uo : F). Proceed by induction on 
the derivation of V b tc u : A to show A k {{u a /T ]uj : A). 


Case 


r b ctx 
F b tc • : • 


. Trivial. 


r b tc U) : A r b 7 : D r ~ v 
rbr : T [t7/A]/c T b v : T [at/A] k 
rb tc (w, (r,r, 7 )) : (A, a : T k) 


Here A fc ([a;o/r]a; : A) by 


induction, and A^Qc^/T] t ~ [cl^/r]u) and A fc ([obo/r]T ~ po/r] v) from part 
(c). Moreover A^QcL^/r] r ~ [bbo/F] r) from part (a). Hence symmetry and 
transitivity give A fc ([<t^/r] t ~ [cJq /F] v) as required. 


Case 


T b tc oj : A 
r b 77 : D [fcb/A] </? 
r b rf : D [rt/A\ ip 
Fb tc (a>, (r), rf)) : (A, c : D tp) 


Let uj' ■ ujqi[uq/T]u. By induction, 


A fc ([o;o/r]a; : A), A k _ 1 ([u t /V, A] <p) and A fc _ i([u//F. A] ip) as required. 


Case 


rb tc w:A 
rb e : A [tb/A] r 
r b e' : A [at/ A] r 
T b tc (a;, (e, e')) : (A, x : A r) 


By induction, A fc ([a;o/r]a; : A). 


□ 
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